Just found out. It is explained here (via the the Target Platform dialog window).
But the only zwave related jar that I have is the prebuilt one (org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar) without my local changes.
I guess I need to somehow specifically set the zwave project with my local changes to build the jar file?
locate zwave | grep jar
/home/avner/openhab2-master/git/openhab2-addonAvner/org.openhab.binding.zwave/lib/junit-4.12.jar
/home/avner/openhab2-master/git/openhab2-addonAvner/org.openhab.binding.zwave/lib/mockito-all-1.10.19.jar
/home/avner/openhab2-master/ws/tmpAvner/org.openhab.binding.zwave-master/lib/junit-4.12.jar
/home/avner/openhab2-master/ws/tmpAvner/org.openhab.binding.zwave-master/lib/mockito-all-1.10.19.jar
**/var/lib/openhab2/kar/openhab-addons-2.1.0-SNAPSHOT/org/openhab/binding/org.openhab.binding.zwave/2.1.0-SNAPSHOT/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar**
Ok you are correct. I was able to run habmin within eclipse and use the source for zwave.
The output log indicates that the initialisation finished for the node
NODE 20: Node advancer: Initialisation complete!
(log here and node xml file here), but habmin claims that it is not fully discovered yet
@chris I’m trying to push this issue forward as much as I can.
Assuming that the workaround and the generation of the xml file, are temporarily good enough, is the HABmin message that “the device has not been fully discovered by the binding” to be expected?
(I do see a question mark near this device and a message “This device is awaiting review following updates.” in http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/140)
Do you recommend that I look into the HABmin code? If yes, can you give me high level pointers on where to start looking within HABmin?
No - none of this is related to HABmin - everything is done in the binding.[quote=“Avner, post:104, topic:16135”]
I do see a question mark near this device and a message “This device is awaiting review following updates.”
[/quote]
Yes - I should update this, but it doesn’t matter as the current definition is already used in the binding, but as I was on holiday at the time I just copied it manually.
No - given it used to be discovered, the database should be ok. I would suggest to delete the thing and add it again (don’t exclude and include though).
I deleted and added the device again (without excluding/including):
Delete the thing - in HABmin → Configuration → Things, clicked on the Delete button, approved the dialog box.
Add the device again - - in HABmin → Configuration → Things, clicked on the “magnifying glass symbol with the plus sign in it”, selected zwave binding, and added the device.
After this, the device shows up in HABmin → Configuration → Things, but without any channels.
I don’t know if this matters but previously, the device showed up in PaperUI as EZMotion, with the channels (although they never worked). Now PaperUI shows “Unknown Device” and there are no channels at all. @chris, should I update to the latest snapshots of the packages (smarthome, openhab-distro, openhab-core, zwave, habmin bindings ) as I repeat the steps? I’m asking because I am concerned of missing the latest updates, but at the same time don’t want to chase after a moving target (e.g. I get different results and I don’t know if the change behaviour is due to a package update)
By the way, every time that I restart eclipse I have to manually wake up the device to complete the initialisation process, it this the expected behaviour? I know that it is required for a battery device when adding it for the first time, but is it required every time?
I’m not really sure why it would have changed - unless of course someone changed the database for this device, but it doesn’t look like this is the case . Does the device type/id show in the XML file?
It shouldn’t really be necessary.
Yes. The first time it downloads a lot of data, but adter this every other time it will download a small amount - just to check the current status.
The device type/id does show in the XML file. Just to be sure, I removed the node xml file and started fresh again. Deleted the device, then added it via HABmin → Things. Went through the initialisation stage once again. After initialisation completes a new file node20.xml is created.
According to the xml file the manufacturer is 0x1e which fits the manufacturer id of EZMmotion Express In the device list here (img1)
In HABMIn / attributes the manufacturer is recognised as 0x1e “Express Controls” but still, it says Unknown Device and there are no channels (see img2)
Also, I do notice the following things:
the protocol version in the device list (Protocol Version 3.052) is different then the protocol version in the xml file (2.40)
when the device is discovered EZMotion Express is not in the list of possible devices. Eventually, after the list of possible devices is scanned I’m getting the message NODE 20: Device discovery could not resolve to a thingType! 001E:0002:0001::1.12
(this can be seen In the log file here)
The latest version that I’m using (latest snapshot - 0e30ac2 Update database (#344)) does not have the file: homeseer_ezmotionexpress_0_0.xml in org.openhab.binding.zwave-master/ESH-INF/thing (where I have an older installation that has it).
After copying the file homeseer_ezmotionexpress_0_0.xml into the latest snapshot, restarting openhab2, and intiialising the device, it shows up as EZMotion Express Wireless 3 in 1 Sensor, with 4 channels
Changing a parameter in Configuration Parameters e.g. On Time from 20 to e.g. 23 does not stick.
I tested the value change by setting a new value (23) via HABmin, manually waking up the device, and clicking Save. I then get a message Thing Saved Successfully, and a yellow icon pending near the field.
After refreshing the page, the new value shows up in HABmin without the yellow icon, and PaperUI shows the new value as well. Also the output log file indicates that the value is changed (snippet 1), But the new value doesn’t persist in the xml file, and the 4 channels are completely useless in PaperUI (img1)
Assuming the file is back in the database, what could be the reason that new configuration values don’t persist?
And why are the channels useless? They show up NaN (see img1 in my previous post)
Note that the protocol version in the database file is different then the one on my device.
I restarted openhab2, initialised the device (node 20), and changed the On Time parameter in Configuration Parameters from 24 to 27 (I think this is logged as: NODE 20: Update CONFIGURATION 2/1 to 27)
The debug log is here
The new value does NOT persist after I restart openhab2 - it shows the original value. Also, the xml file always show the original value.
Also, in order to persist the new value, just before pressing Save (in Habmin, Configuration, Things), I press the button on the device to wake it up. I’m not sure if this is the right thing to do since the log file shows NODE 20: Starting initialisation from DONE. I hope I’m not starting the initialisation again.
The items/channels always show NaN, even if I refresh the PaperUI Control page after a while.
Is there a way to check that the channel values are transmitted? (maybe through the log file?)
I’m saying useless, because ultimately the goal is to get readings (e.g. temprature) from the device.
Is there a way to trigger an update of these channels / items from the device?
Also, do I need to define / create channels, items, or sitemap in order for these items to work properly? I’m asking because right now I’m only initialising the device - I have not edited any files such as .items or .sitemap (for reference, I do have another outlet device, and it works properly, i.e. turns the switch off / on from the PaperUI control, without any special configuration)
(I do see the items defined in ~/openhab2-master/git/openhab-distro/launch/home/userdata/jsondb/org.eclipse.smarthome.core.thing.Thing.json but I did not specifically create or manipulate this file in any way)
I do notice that I don’t have a temperature channel in the xml file that is being created during the initialisation.
In fact, all the 3 endpoints have the same information (they repeat the command classes of the device)
For example, for some reason command class is added to endpoint1, although only TEMERATURE should be added. I see the following log message
Endpoint 1: Adding command class MULTI_INSTANCE.
It looks to me that the commandClass that is created in ZWaveMultiInstanceCommandClass.java:413 is wrong (e.g. MULTI_INSTANCE instead of TEMPERATURE)
Another user who has an HSM100 device that works ok (although with a newer firmware) shared his xml file for comparison - his xml file does have a temperature channel. @chris can you take a look at the xml file that is being generated (here) and see if it makes sense at all?
(for comparison, here is the other xml file that works ok for another user)
Thanks
@chris, after some more digging, I think that the “Multi-channel capability Report” payload is incorrect, or that the processing of it is wrong.
The result of the processing is 9 command classes (MULTI_INSTANCE, SENSOR_MULTILEVEL, CONFIGURATION, WAKE_UP, ASSOCIATION, BATTERY, MANUFACTURER_SPECIFIC, NODE_NAMING, VERSION) that are being added to each of the 3 endpoints in the node xml file (also see log file snippet1 below).
In the xml file, within the SENSOR_MULTILEVEL, the multiLevelSensorCommandClass
does not have any sensors/multilevelSensorType information
does have a “endpoint reference” field that points 4 levels up, i.e to the endpoints entry
But what it should be is:
endpoint1 - (SENSOR_MULTILEVEL with multiLevelSensorCommandClass/sensors/multilevelSensorType GENERAL, BASIC)
endpoint2 - (SENSOR_MULTILEVEL with multiLevelSensorCommandClass/sensors/multilevelSensorType LUMINANCE, BASIC)
endpoint3 - (SENSOR_MULTILEVEL with multiLevelSensorCommandClass/sensors/multilevelSensorType TEMPERATURE, BASIC)
as in the reference xml file (that another user shared) (should be downloaded for viewing since it fails to parse by the web browser)
snippet1
cat ~/avner/Dropbox/Public/zwave.log
...
2016-11-02 23:16:13.242 [DEBUG] [ZWaveMultiInstanceCommandClass:307 ]- NODE 32: Process Multi-channel capability Report
2016-11-02 23:16:13.242 [DEBUG] [ZWaveMultiInstanceCommandClass:313 ]- NODE 32: Endpoints are the same device class = true
2016-11-02 23:16:13.242 [DEBUG] [ZWaveMultiInstanceCommandClass:386 ]- NODE 32: Endpoint Id = 1
2016-11-02 23:16:13.242 [DEBUG] [ZWaveMultiInstanceCommandClass:387 ]- NODE 32: Endpoints is dynamic = false
2016-11-02 23:16:13.243 [DEBUG] [ZWaveMultiInstanceCommandClass:388 ]- NODE 32: Basic = Routing Slave 0x04
2016-11-02 23:16:13.243 [DEBUG] [ZWaveMultiInstanceCommandClass:390 ]- NODE 32: Generic = Multi-Level Sensor 0x21
2016-11-02 23:16:13.243 [DEBUG] [ZWaveMultiInstanceCommandClass:392 ]- NODE 32: Specific = Routing Multilevel Sensor 0x01
2016-11-02 23:16:13.243 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class MULTI_INSTANCE
2016-11-02 23:16:13.243 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 1: Adding command class MULTI_INSTANCE.
2016-11-02 23:16:13.243 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class SENSOR_MULTILEVEL
2016-11-02 23:16:13.243 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 1: Adding command class SENSOR_MULTILEVEL.
2016-11-02 23:16:13.243 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class CONFIGURATION
2016-11-02 23:16:13.243 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 1: Adding command class CONFIGURATION.
2016-11-02 23:16:13.244 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class WAKE_UP
2016-11-02 23:16:13.244 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 1: Adding command class WAKE_UP.
2016-11-02 23:16:13.244 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class ASSOCIATION
2016-11-02 23:16:13.244 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 1: Adding command class ASSOCIATION.
2016-11-02 23:16:13.244 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class BATTERY
2016-11-02 23:16:13.244 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 1: Adding command class BATTERY.
2016-11-02 23:16:13.244 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class MANUFACTURER_SPECIFIC
2016-11-02 23:16:13.244 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 1: Adding command class MANUFACTURER_SPECIFIC.
2016-11-02 23:16:13.245 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class NODE_NAMING
2016-11-02 23:16:13.245 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 1: Adding command class NODE_NAMING.
2016-11-02 23:16:13.245 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class VERSION
2016-11-02 23:16:13.245 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 1: Adding command class VERSION.
2016-11-02 23:16:13.245 [DEBUG] [ZWaveMultiInstanceCommandClass:386 ]- NODE 32: Endpoint Id = 2
2016-11-02 23:16:13.245 [DEBUG] [ZWaveMultiInstanceCommandClass:387 ]- NODE 32: Endpoints is dynamic = false
2016-11-02 23:16:13.245 [DEBUG] [ZWaveMultiInstanceCommandClass:388 ]- NODE 32: Basic = Routing Slave 0x04
2016-11-02 23:16:13.245 [DEBUG] [ZWaveMultiInstanceCommandClass:390 ]- NODE 32: Generic = Multi-Level Sensor 0x21
2016-11-02 23:16:13.245 [DEBUG] [ZWaveMultiInstanceCommandClass:392 ]- NODE 32: Specific = Routing Multilevel Sensor 0x01
2016-11-02 23:16:13.245 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class MULTI_INSTANCE
2016-11-02 23:16:13.245 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 2: Adding command class MULTI_INSTANCE.
2016-11-02 23:16:13.246 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class SENSOR_MULTILEVEL
2016-11-02 23:16:13.246 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 2: Adding command class SENSOR_MULTILEVEL.
2016-11-02 23:16:13.246 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class CONFIGURATION
2016-11-02 23:16:13.246 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 2: Adding command class CONFIGURATION.
2016-11-02 23:16:13.246 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class WAKE_UP
2016-11-02 23:16:13.246 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 2: Adding command class WAKE_UP.
2016-11-02 23:16:13.246 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class ASSOCIATION
2016-11-02 23:16:13.247 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 2: Adding command class ASSOCIATION.
2016-11-02 23:16:13.247 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class BATTERY
2016-11-02 23:16:13.247 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 2: Adding command class BATTERY.
2016-11-02 23:16:13.247 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class MANUFACTURER_SPECIFIC
2016-11-02 23:16:13.248 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 2: Adding command class MANUFACTURER_SPECIFIC.
2016-11-02 23:16:13.248 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class NODE_NAMING
2016-11-02 23:16:13.248 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 2: Adding command class NODE_NAMING.
2016-11-02 23:16:13.248 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class VERSION
2016-11-02 23:16:13.248 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 2: Adding command class VERSION.
2016-11-02 23:16:13.248 [DEBUG] [ZWaveMultiInstanceCommandClass:386 ]- NODE 32: Endpoint Id = 3
2016-11-02 23:16:13.248 [DEBUG] [ZWaveMultiInstanceCommandClass:387 ]- NODE 32: Endpoints is dynamic = false
2016-11-02 23:16:13.248 [DEBUG] [ZWaveMultiInstanceCommandClass:388 ]- NODE 32: Basic = Routing Slave 0x04
2016-11-02 23:16:13.248 [DEBUG] [ZWaveMultiInstanceCommandClass:390 ]- NODE 32: Generic = Multi-Level Sensor 0x21
2016-11-02 23:16:13.248 [DEBUG] [ZWaveMultiInstanceCommandClass:392 ]- NODE 32: Specific = Routing Multilevel Sensor 0x01
2016-11-02 23:16:13.248 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class MULTI_INSTANCE
2016-11-02 23:16:13.249 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 3: Adding command class MULTI_INSTANCE.
2016-11-02 23:16:13.249 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class SENSOR_MULTILEVEL
2016-11-02 23:16:13.249 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 3: Adding command class SENSOR_MULTILEVEL.
2016-11-02 23:16:13.249 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class CONFIGURATION
2016-11-02 23:16:13.249 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 3: Adding command class CONFIGURATION.
2016-11-02 23:16:13.249 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class WAKE_UP
2016-11-02 23:16:13.249 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 3: Adding command class WAKE_UP.
2016-11-02 23:16:13.249 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class ASSOCIATION
2016-11-02 23:16:13.249 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 3: Adding command class ASSOCIATION.
2016-11-02 23:16:13.250 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class BATTERY
2016-11-02 23:16:13.250 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 3: Adding command class BATTERY.
2016-11-02 23:16:13.250 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class MANUFACTURER_SPECIFIC
2016-11-02 23:16:13.250 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 3: Adding command class MANUFACTURER_SPECIFIC.
2016-11-02 23:16:13.250 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class NODE_NAMING
2016-11-02 23:16:13.250 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 3: Adding command class NODE_NAMING.
2016-11-02 23:16:13.250 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:241 ]- NODE 32: Creating new instance of command class VERSION
2016-11-02 23:16:13.250 [DEBUG] [ZWaveMultiInstanceCommandClass:426 ]- NODE 32: Endpoint 3: Adding command class VERSION.
Just as an aside I appear to be having the same issues as avner.
I just installed openHAB on a RaspPi3 via openhabian and everything seems to be working apart from the HSM100’s.
The Z-Wave power switches are fine as you can see on the attached screenshot as they switch on and report the wattage consumption.
I am assuming the HSM’s are configured okay as a) they configured okay and operate okay when I installed homeassistant and b) they are accurately reporting the battery level. All the other fields (temp, luminance) either report -Nan/NULL or after a few screen updates a 0 value.
If you want me to pull out any logs etc for comparison purposes with avner let me know (otherwise I’ll keep a watch on this thread). If anything is required please err on the side of telling me how to suck eggs as I’m relatively unfamiliar with openhab (okay with Linux).
After more than 4 months, I got to say that I’m a bit frustrated with not being able to make use of the HSM100 device
I finally gave a try to Home Assistant. Within few minutes I was able to install the system!! I couldn’t believe it when the HSM100 device popped up on the first zwave inclusion and immediately showed the temperature.
I’m going to give Home Assistant a try and keep monitoring this thread. I’m definitely not giving up on OpenHab,. @chris, thanks for your help and efforts so far.
Openhab set up but wouldn’t give me any data other than battery from the HSM100. I loaded up homeassistant and it read the data first pop.
Great I thought! I can deal with the fairly mundane interface with limited configuration possibilities and yaml config files.
I then noticed that the HSM was only being updated when I reboot the PI. The rest of the time it just stored the data, so was virtually useless to run a virtual thermostat off.
Let me know how you get on and if yours update with each polling (I didn’t manage to examine whether they continued polling after the first boot as the base install zwave utilities on homeassistant aren’t anywhere near as comprehensive as habmin).
So far I’m getting results for luminance, temperature, and battery. I’m not sure if it is actually polling because the values are fixed, but I have only ran it only for 20 minutes. I’ll give it to run and let you know if the values actually change with each polling.
. Does the device type/id show in the XML file?
