I am able to go through the inclustion process and everything is online an running. However, it gets incorrectly identified as a different thermostat, the Z-TRM2 (https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/854). There is quite some difference between the two. The parameters and accosiation groups are different, which means that I am having some issues now…
My Thermostat has firmware version 3.6 (the newest).
Is this a database issue, or is there some sort of workaround in openhab I can implement in order to get the correct settings?
Likely new features were added with the newer firmware.
With the XML file generated by OH and a pdf of the manual, it can be added to the database. If you wish to try, here is the database guide.
I have checked the manufacturer manual, and there is no difference from the 3.4 version which is already included in the cd-jackson database. My thermostat gets identified as a firmware version from 2.6 to 2.255 (i.e. Z-TRM 2, which is totally different). It it not identified as Z-TRM2fx with firmware 3.6, which it should.
Here is the differences between the two thermostats:
Manufacturer: same (019B)
Type: same (0003)
Id: same (0202)
firmware: different
Z-TRM 2 (from 2.6 to 2.255)
Z-TRM2fx (from 3.0 and above).
This means that the only thing to destiquish these two in the identification process is the firmware version (according to the DB guide). So then I assume there is something wrong in the cd-jackson DB. I could most likely easily fix this myself, but I don’t have write-privileges to the database yet (just registered as this is my very first zwave device).
Would appreciate if someone with write-access to the database could help out, and test my hypothesis.
Maybe the firmware versions entry for the Z-TRM 2 in the database should be “2.255 to 2.6”, instead of “2.6 to 2.255”. Just guessing…
Version numbers can only be between 0 and 255 for both the minor and major versions - so that means 0.0 to 255.255. I’m not sure how we can now have a version with 600?
Version of 2.6, is exactly the same as version 2.006. 2.600 is totally invalid.
Can you explain this point please? I don’t understand what this statement means?
I’m now home - rather tired and heading to bed soon as it’s now 4 in the morning in whatever timezone my body thinks it’s in
It seems like the Z-TRM 2 is out of production and replaced by the Z-TRM2fx (just by browsing the z-wave alliance website).
The latest firmware version for Z-TRM 2 is 2.9 (got it from from the linked manual in the DB).
So I guess that the correct “firmware versions” value for Z-TRM 2 in the DB should be: “from 2.0 to 3.0” (from 0002.000 to 003.000). It should be from version 2.0 to avoid messing with earlier thermostats versions if those even exists…
And for the Z-TRM2fx it should be all above 3.0. Just the way it already is.
- sorry, I’m a bit tired so I’m not sure of your point.
ZWave versions are 2 numbers - a minor and major part separated by the dot. So in this example, the major version is 2, and the minor is 6 to 255. This is perfectly fine. 255 is the maximum number allowed since the version is an 8 bit value (hence 0 to 255).
2.1 is the same as 2.01 since in both cases the minor value is 1. 2.1 is NOT the same as 2.10 since the minor version is now 10.
In the database, you use a value of 600 - this doesn’t fit in an 8 bit value so cannot be correct no matter what counting you’re using.
You are right. latest is 2.9 and thats what it should be.
Im feeling the discussion is going off topic. What could be the reason that my Thermostat v. 3.6 is getting identified incorrectly, and shows up as the thermostat previous (by far) to my version?
Most version numbering systems I know of use a system of major . minor . patch - this includes openHAB. So, the next version after version 2.9 doesn’t become 3.0, it becomes 2.10 - therefore 2.10 is clearly not the same as 2.1 and you can’t treat version numbers as a simple decimal number.
As I say - openHAB uses exactly the same system. openHAB 1 current version is 1.14 - that’s the 14th version - starting at 1.1 and not 1.01.
Possibly, but if people don’t understand how versioning works, then devices will be identified incorrectly, and that is exactly the topic here isn’t it?
I’m not sure what the versions of these devices are - possibly the manufacturer is also differentiating these as different products (using different type/id codes) in which case it’s a more complex issue.
It is the topic, but now that you have clarified for us how the versioning works, it seems like the problem must be elsewhere.
As you can see from my previous post, the problem is that my thermostat gets incorrectly identified in the inclusion process. My thermostat is Z-TRM2fx (fw ver. 3.6), but it gets identified as Z-TRM 2 (fw ver above 2.6).
This is what HABmin attributes looks like, but it still gets identified as Z-TRM 2. It should have been identified as Z-TRM2fx.
Yes, as I said, probably we have incorrect type/id values attributed, but this is a much more difficult mess to resolve as we may also cause other problems.
We need to try and understand the different type/ids that are used on these devices. The best way is if the manufacturer can provide this information. If we need to try and work it out, it will be problematic unfortunately.
- sorry, I’m a bit tired so I’m not sure of your point.