What I don’t get: Is Aeotec short of device types/IDs? 
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.
No hard facts, but:
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 
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 
).
I’ll send them an email - I have a good contact there.
Here is the reference:
Ok, so we have the definitive answer from Aeotec.
ZWA009 firmware version is V1.XX, there is a V12.01 custom firmware update available to try to improve the report time of the ZWA009 for those that have it (increase static threshold checks to 4 minutes per check, allow lower setting for parameter 4 timed reports). V12.01 can be found here as a .GBL file: https://help.aeotec.com/support/solutions/articles/6000253486-update-zwa009-aerq-sensor-v12-01
ZWA039 firmware version is V2.XX which utilizes the same identifiers, the main difference seen in firmware is this firmware identifier. There are a lot of differences with this version, the main reason the named model number is difference is because its hardware has been changed greatly:
- Additional and expanded parameter settings from ZWA009
- Updated Z-Wave SDK library used (i believe 7.15)
- Better pairing detection and LED activity (more clear when it pairs)
- Better sensors with better accuracy
- Better battery sensor design for improved voltage detection
- Improved hardware, button press detection, and casing design
So, based on this we would need to create a new version of ZWA009 with Version=12, change the current ZWA009 to V=1.000-1.255, and set the new ZWA039 to 2.000-2.255.
Most of this is easy - but as we don’t have an XML for the ZWA009 with version 12, that is more difficult. I propose for now to leave this since it seems to not be too common (based on the “for those that have the problem” statement in the above). When someone comes along with the new V12 we can create that entry - or if someone already has that, or possibly even another ZWA009 XML that we can use we could hack the versions to get this included.
I should also add that this still doesn’t tie up with the image above from ZWaveJS, but let’s ignore that as I’ve no idea where that info came from.
1 Like
The new sensor was discovered with all parameters. Thank you and Ap15e for the help.
There are high ceilings in our house and we have ceiling fans in 3 rooms. My objective is to place a ZWA039 sensor on the ceiling of a room and compare the temperature reading to an Ecobee remote sensor for that room. If the temperature of the ceiling sensor exceeds the Ecobee sensor temperature then a command would be sent to the ceiling fan to turn it on.
3 different setups(briefly):
(Quantity Type checked and Item metadata added to State Description>pattern)
1: IF ZWA039 temp > Ecobee, then send command to fan
2: IF ZWA039 temp > 73, then send command to fan
3: IF ZWA039 temp > 73, then turn alarm ON
For each setup a script was created and tested then disabled. Then a Rule was created for each and tested. When each Script and Rule was run (forced) the expected outcome resulted. However, during normal operation none of the setups triggerd a send command.
After reading several Community discussions on related observations I decided to check the Parameter and Association settings for each ZWA039. What I found was that Parameter configurations and Association are not being set (persistent) after restarting. Changes cannot be saved without setting Parameter 255 to 1 or greater (meaning reset device to default settings) while the default value is 0. It seems setting the value to 1 or more while allowing saving configuration pending restart, resets all paramaters & associations to default values and none are saved.
This affects three seperate sensors and deleting & rediscovery doesn’t solve the problem. Log (TRACE & DEBUG) do not seem to lead to any specific error. I would appreciate further thoughts on how to meet my object (short of employing other sensors).
OS = Ubuntu 20.04
OpenHAB = 3.2.0-SNAPSHOT - Build #2616
I picked up a ZWA039 recently, and my install (3.1.0) recognized the device as a ZWA009. It isn’t operating as expected (updates not consistent, parameters not updating). Since 3.2 release is coming, I will probably wait for that instead of updating the binding. My question is about the process to update the device. Should I just delete the thing and rediscover (and hopefully as a ZWA039), or do I need to exclude the device from the controller? Just prepping for the change.
I have made some updates to the current database entry that fixes some problems. (a minimum of 1 but a default of 0). Especially a bit troublesome for the reset parameter that needs a 0 to not reset 
I have tested this locally with an updated XML
However I still encounter one issue parameter 4, (periodic update interval) has a default value of: 43200. However the device updates this back to -22336. It sound to me like a signed/unsigned mismatch. But it is unclear to me how to change this in the database. Do you have any advice on how this can be handled?
1 Like
Hi SjoerdT,
i just added my second AERQ to my network. I also updated to 3.2.0 some days ago coming from 3.2.M1
I found that my first AERQ doesn’t work anymore and that i can’t access the configuration of this one giving me an error message only:
For the second: I can’t save anymore as it always says that i have to set a minimum value of 1 for the Reset Parameter.
But i think this means that the sensor will reset everything to default after setting this up?
I’m a bit confused what to do right now. Any idea?
For the first device I would try to disassociate and re-associate it so it will take the latest XML. For the reset issue, I have provided an update in the z-wave database of @chris. I expect this is not yet in the 3.2.0 build. In my home setup I took a manual build of the z-wave plugin, added the updated XML to the jar and loaded this. This works with the exception of the signed/unsigned issue I described in my earlier post.
As noted above there were changes to ZWA039 and ZWA009, with the last approval of ZWA039 after OH3.2 was released, meaning it probably wasn’t in the zwave binding for 3.2.0. (Devices that are modified, but not approved in the DB are deleted from the binding for a couple of cycles) May need to upgrade to zwave 3.3 snapshot. If the advice above doesn’t correct the problem.
Bob
The changes cannot be added to the 3.2.0 build - this build is a “one time” build and won’t change. If you need to use the new feature, then you must use a new snapshot. This will be in the NEXT stable release though.
No - that’s incorrect. Just because a device was edited after a release, doesn’t mean it wasn’t in the last release. This device was available, but as the reset feature was only added in the last couple of weeks, this feature was not in the last stable release - but the device itself was there.
I did hedge with “probably” as I did not go through all the code changes on the DB updates around the time OH3.2 was released. Whenever a previously working device starts acting up and the device DB shows an approval anywhere around the same time ± 7 days, I feel it is worth mentioning as a possibility. (and has been the solution several times)
Bob
1 Like
thanks for clarification and for maintaining! 
As the OP, of course I end up being the person with ZWA009 units on FW 12.01.
With the device in-hand, is there something I can do to discover the XML for this combination (e.g. Z-Wave PC Controller), or is that something that has to come from Aeotec?
If i could find a 1.x image, I’d just downgrade the ROM.