Two brand new Aeotec Z-Wave devices to add to the database

I’ve just purchased one of the Temperature and Humidity sensors and can report that it works really well. No issue with getting is on the network and after a few manual wake up’s, all the end points are reporting as they should.

FYI I’m running OH2.5 at the moment, I plan to migrate of the course of this year.

1 Like

Aeotec ZWA039-A Temperature & Humidity Sensor seems to be a new version of ZWA009. It is not in the Open Smarthouse Database as yet. Is anyone using this sensor and requested a database update?

Without the XML file for the device there is no hope to have it added to the Z-Wave database, see

1 Like

Thanks for the response. The Guide does show a method to create a new device without a XML file. I’m not sure if this is the correct approach since the ZWA039 has the same Manufacturer ID and Device Type (although 0371 is an added listing). The Device ID (Label) and Firmware are different.

It’s really not recommended, and doesn’t gain anything at all. It is prone to people entering incorrect information - it is much better to simply upload the XML file to the database and have that generate the majority of the detailed information. You then only need to add the associations and configuration (and manual etc).

According to https://devices.zwave-js.io/ ZWA009 identifies itself as
0x0371:[0x0002:0x0009, 0x0102:0x0009, 0x0202:0x0009]
and ZWA039 as
0x0371:[0x0002:0x0009, 0x0102:0x0009, 0x0202:0x0009] -
you are right, the IDs are the same, but the parameter set seems to be different.

According to https://devices.zwave-js.io/ ZWA039 can be identfied by its firmware: 2.0 - 10.255. So we would need to restrict the ZW009 to firmware versions ( <= 1.255 or 11.1), create a copy of ZW009, add the new parameters, rename the copy of ZW009 to ‘ZW039’ (@chris: or rename all versions to ‘ZW009/ZW039’?) and restrict it to firmware versions 2.0-10.255 - a lot of work that should be based on the XML file from the device (and not on dubious information on the internet).

1 Like

OH lets me add a thing (unknown device) but no XML file is created (/var/lib/openhab/zwave).

Also log file shows communication but then no state update (node 11):

I still am learning OH so at a loss where to go from here apart from using a different sensor. Thanks for the help.

Update & Solved:

Once I “woke-up” the sensor close to the controller, OH recognized it and all the channels are active. No need to amend the database unless to note that this version works as well.

Could you post the XML file for ZW039, please? It should be located in userdata/zwave. Before posting the XML file you might want to remove the <homeId>...</homeId> - not sure whether Google is sniffing Z-Wave home IDs, though. :slight_smile:

Aeotec_ZWA039.xml (20.2 KB)
Attached is the file.

1 Like
<protocolVersion>7.15</protocolVersion>
<applicationVersion>2.0</applicationVersion>
<hardwareVersion>1</hardwareVersion>

This confirms that ZW039 could be discerned from ZW009. Right now your ZW039 is ‘missing’ the following configuration parameters:

  • #3 Threshold Check Interval
  • #16 Check Interval for Parameter 5, 6, 7, 8
  • #65 Sensor Report after Inclusion: Battery, Temperature, Humidity, Dew Point

To add these parameters to the database, follow the steps described in Two brand new Aeotec Z-Wave devices to add to the database - #13 by Ap15e. :slight_smile:

Just to be clear - if the older (or other) version of the device doesn’t support these configuration parameters, then we would require a new database entry, so please don’t add them to the current entry if this is the case.

1 Like

From what I read on the Aeotec site ZWA009 has FW ver 12.01 which still does not match ZWA039 parameters. So I think that necessitates a new db entry,

What I don’t get: Is Aeotec short of device types/IDs? :frowning:

@chris

We would need to punch a hole in the version space of ZW009:
version < 1.255 OR version >= 11.1

Does the Z-Wave database support this? Or do we need three different ‘devices’ in the database (ZW009 < 1.255, ZW009_1 >= 11.1, ZW039 2.0-2.555)?

No, the database doesn’t support this - we’d need multiple entries.

Before heading down that path though, I’m a little surprised there’s an overlap here. Aeotec don’t normally do this, and it is against the certification requirements so we should entertain other possibilities.

Where did you read this? It is not in the official Aeotec documentation which shows that the ZWA009 is V1, and the ZW0039 is V2 of the firmware. Now this might be wrong, but I’d like to clearly reference this if we’re going against their documentation as they are normally one of the better companies out there.

Attached is the Aeotec document.

Update ZWA009 aerQ Sensor V12.01 _ Aeotec Help Desk.pdf (79.9 KB)

No hard facts, but:
grafik

The only difference I can find:

Automatic Reporting Interval

  • <= 1.255 Allowable Range: 900-65535
  • =11.1: Allowable Range: 30-65535

We would have to check the firmware history of ZW009 to be sure …

Before heading down that path though, I’m a little surprised there’s an overlap here. Aeotec don’t normally do this, and it is against the certification requirements so we should entertain other possibilities.

Agreed. Maybe someone should ask Aeotec? It looks like a certification bypass for ZW039 …

The problem with relying on this sort of community information that you reference here with ZWaveJS is that sometimes people entering the data don’t get it right, so errors get propagated. Assumptions are made that devices are the same, so type/ids get added to devices that are “the same”, and then later it’s discovered that they aren’t the same…

I say that from experience as that is exactly what happens in the OH database as well. I don’t blame anyone - the information can be damn hard to come by, and at times it’s impossible, so assumptions get made. On the other hand, sometimes people are just lazy and it’s easier to add a type/id to an existing device that’s “nearly the same” and get 99% of the functionality with no work :wink:

Anyway, I’ve spent quite some time trying to recover devices from such issues in our database, and this seems another example.

I’m interested in the statement above -:

@rcrail please can you provide a reference for this? Ideally a link so we can check this, or at least we know where the information came from for future reference when someone complains that we’ve mixed up devices (which is normally the next step on this journey :slight_smile: ).

I’ll send them an email - I have a good contact there.