Z-wave binding help trane already tried loading snapshot binding.zwave-3.3.0-SNAPSHOT.jar

1

New to openhab (well 3rd try getting it running since 2.5)
Not new to software development.
Reviewed all options out there
Selected Z-Wave, OpenHab and Trane as first venture.

Start with fresh install of Pi 4 (not from image) 3.2.0
Had below issue.
Also persisting after trying org.openhab.binding.zwave-3.3.0-SNAPSHOT.jar by loading into addons directory (and clearing karaf)

Getting the zwave binding connected works with adding (take this to mean it loaded from addons)
Getting the thermostat connect works (Z-Wave Node 002: Trane XR524 Touchscreen Comfort Control Thermostat)
Get the error when even trying to save the new thing.
(Very suspicious that config parameter 21 is being loaded with a value of 21 and cp24 is being loaded with a 24)

Display Lock

  • 21: Cooling Delta Stage 2 OFF
    Please select a value that is no more than 8.
  • 24: H/C Delta
    Please select a value that is no more than 15.

Checked the xr524_0_0.xml values are not in that section.
binding is just behaving like the value is being set to the config number

  <parameter name="config_21_1" type="integer" groupName="configuration"
             min="0" max="8">
    <label>21: Cooling Delta Stage 2 OFF</label>
    <description><![CDATA[

Cooling Delta Stage 2 OFF

Overview

Sets the delta from setpoint that stage 2 cooling stops. Stage 1 turns off at setpoint minus (-) Delta Stage 2.


]]>
0

Any suggestions next steps to triage further?

2

I could not understand the error you are having exactly. As a starter suggestion we have a community-maintained database here. Your device is listed here. You sign up for access and get a few more details on the device parameters. Modifying them requires a creating a ticket.

The only thing I can add is that you should not need the snapshot binding. The last modification to this device was in 2019.

Welcome,

Bob

3

Sorry, I was not super clear, hopefully this image is better idea.
Best description I can come up with is.
Openhab will not let me save this “thing” while validating settings of configuration parameters, even after I update them and save.
It give error in red that value us outside of range defined in xml
(coincidentally the value for the config parameter is also being set to the configuration parameter number)

Issue was also reported in this thread about devices not updating, which was marked solved by manually updating zwave snapshot binding

image
image738×235 3.87 KB

4

The configuration parameters for 008B:5452:5442 in the Z-Wave database are completely different from the data in the Z-Wave JS Config DB.

Might be related:

5

Okay @bernie_xg I see what you are talking about. I recall a similar problem with another device (but can’t remember how it was resolved). There are two things to try; first see if you can change the parameters on the Thing “Code” tab & save. Second, try to use the Develop tools–>API explorer -->Things -->Put Things{Thing UID}. First use the GET to see how the parameters are set-up.

@anon71759204 I’m not following your thought. Are you saying there might be something that has to be changed in the OH database to match the JS Config DB that also seems to have issues?? I agree they are different, but @bernie_xg is using OH3 zwave binding. The mystery to me is why the parameters are being populated incorrectly. I do not see anything with the OH3 zwave DB that would cause that. Please clarify.

Bob

edit: Also found another post with another suggestion

6

What makes you think that @bernie_xg 's device does match the data in the Z-Wave database? Without access to the manual for @bernie_xg 's device one doesn’t know.

7

I guess the fact it was discovered and the parameters are showing up in the UI,

Getting the thermostat connect works (Z-Wave Node 002: Trane XR524 Touchscreen Comfort Control Thermostat)

so, the DB ID and device references must match. Granted it could be a newer device (with a different “version”), but usually the maker adds parameters and not deletes existing ones.

Anyway, I did provide links above to both the DB and the device so he can check versus his manual and alert us to any differences.

Bob

8

thank you all for all your help
When saving thing, with pre-populated values (eg 24 for config 24) I get the validation error and a warning.
When I fix values to acceptable values the openhab warnings clear, and I hit save and get no message.

I think what I did not notice before, is the save is failing silently, without updating, because I get a different warning pop up when I navigate away from that screen

And thanks for other link and tip about developer API. Will explore that as well as logs and report back

9

It looks to me like manufacture reference number matches the zwave database ref (if I am looking at the right thing)

    "properties": {
      "zwave_class_basic": "BASIC_TYPE_ROUTING_SLAVE",
      "zwave_class_generic": "GENERIC_TYPE_THERMOSTAT",
      "zwave_frequent": "false",
      "zwave_neighbours": "1",
      "modelId": "Trane XR524",
      "zwave_listening": "true",
      "zwave_version": "1.38",
      "manufacturerId": "008B",
      "manufacturerRef": "5452:5442",

I am able to do an API get, but not following how that helps me do a put, I was looking for some reference on populating the body and did not find that yet (I did follow getting the UID for the device)

I did see an error in the logs, that let me to this post https://community.openhab.org/t/aeotec-zw100-temperature-calibration-value-no-message-body-writer-has-been-found-for-class-java-util-collections-unmodifiablemap-contenttype/112479/31

Long story short… Openhab tries to update all config parameters, advanced and not. I did not have advanced checked, so it would pass the validation, have no popup, log the error while updating a config parameter, and not save, and not pop up. So was able to save when updating with advanced checked.

So that seems to be working now.

On to my next task of updating device xml to make it easier to set the programming setpoints.
by breaking the 4 byte time, temperature into 4 bytes and create channels in the XML database.

Thanks again for your help

228: Schedule Sun-1
118439757
Schedule Sun-1
Overview
This value holds information about the first schedule setpoints for Sundays.

Byte 1: Hour   (0-23)
Byte 2: Minute (0-59)
Byte 3: Heat Setpoint (degrees)
Byte 4: Cool Setpoint (degrees)
Default:  0x06004643 06:00AM 70F / 67F

      0x06001519 06:00AM 21C / 25C
1 Like
10

What I do is get the get, hit the copy icon. Open the put and paste, then make changes in the pasted field, then execute.

The mystery for me is why your parameters are being populated with something besides the default values in the zwave DB, but it sounds like you are working around it.

Bob

11

Ding…
After playing with parameters XML, the thermostat and OH3 a few days, I now understand better what you are saying about the parameters in the different databases being different. (As well as some parameters talk about 3rd stage, and the manual doesn’t even describe this)

These parameters dont come from any published source in this case, and all have been reverse engineered? (So results may vary…)

I suspect strongly several of these are just not correct in the Z wave database and should probably be updated/removed.

I understand ideally, would get some updates made to the database.
While I am testing, any good streamline steps for updating XMLs in the addons binding and restarting OH? Or maybe a better different tool to check validated the config parameters in a Z-wave device.

12

A quick search on the Internet does not reveal any official specification of the Z-Wave configuration parameters for Trane devices. There seem to be different versions of the device with possibly different firmwares and different configuration parameters. It might even be that these different devices can’t even be told apart by their Z-Wave IDs (just speculating). A pretty messed up situation.

13

This was written for OH2.5 to modify add/modify a device xml file in the .jar (ESH-INF is now OH-INF). I used it once a few years ago. Now if I have edited the DB, I just wait, as it is only a few days before a new snapshot zwave binding is created. For testing another option is to recompile a local .jar from the github code.

Bob

14

thats great thank you much
I was doing a 2 step process,
updating the xml in the zwave.jar
and then updating that jar in the addons.kar…

Anyone able to direct to something like z-wave utility to test config parameters? It looks like I am going have to reverse engineer some of these.

15

I do not know of anything like that.

One thing to try, and I think I did this successfully (my notes are bad), but if you simply add the parameter in the API (in the correct format - I had the manual) it will get sent to the device. I recall I was doing this for a while until I just modified the xml and ultimately the zwave DB, so I could make the change in the regular UI.

Bob

16

Circling back with what I have learned after doing a lot of playing around, log inspection and exhausting search engines

  • the zwave binding openhab uses gets “the list of config parameters” from the XMLs (which are created from the database). It then polls those config parameters for their current value. At least this thermostat, if not other devices, returns the config parameter “as if” it was the value, if the config parameter is not a parameter supported by the device. e.g. cp 24 always returns a 24 and doesn’t save, because the device simply doesn’t support cp 24.
    This means it is very likely anyone seeing a config parameter behave this way, it is likely not supported by the device and a database update is needed (I have requested access to update the database.
  • I have read similar conversation over at other sites that use zwavejs and a few other places. This does not seem to be a version of device issue in this instance, rather it seems to trace back to openzwave and the uses of a trane624 xml for the trane524 device.
  • Below are config parameters I think need updated.
    Suspect 16,17,18,19,21,24 dont exist and just need removed from the XML
    Seeing some posts suggesting
    71 is the Maximum Heat Setpoint
    72 is the Minimum Cool Setpoint
    76 Shedule 1 Run 0 hold <= I have confirmed this one.
    77 0 2:ESM
    20 Still trying to determine
17

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.