Z-TRM2fx device database update

JensH · January 31, 2019, 8:20pm

In Snapshot 20190128_0928 Voltage comes to Voltage.

For the other changes looks like I have to wait for newer Snapshot

JensH · February 10, 2019, 3:36pm

Update: channels looking good with latest snapshot. I‘ll test them all and will give a final response here

chris · February 10, 2019, 3:48pm

The device is reporting that it supports it - this is how it got added to the database in the first place (ie by reading the XML that someone provided - the XML comes directly from the data the device reports).

JensH · February 10, 2019, 4:36pm

But Device never sends any value to it, I tried to deal with it and it doesn’t fit.

For the new Temperature Setpoints (Param9 and 10) is there a way in Configuration, that I can send the Temperature directly?

Actual Situation: Change Temperature on Device direct to 5.0 changes setpoint1 in Openhab to 5.0 Degrees. Thats o.k., Change in Openhab2 to 5.0 sets Device actual Temperature to 5.0 °C.

In Channels Param 9 and 10 its shown as 50° C, would be nice if there is a way, it would be 5.0°C automatically.

If I send 10.0 from Openhab now to new Channels Param 9 and 10, it doesn’t fit, Think because lowest Temperature is 5.0 Degrees. Is there a Way, if I send 10.0 the Channel changes to Value 100 for right parameter? And if Channel received a 150 to show as 15.0 in Openhab?

Only a Question Don’t know how much options you have got configurating those Channels.

chris · February 10, 2019, 4:40pm

Quite possibly - there are many instances where devices report their functions incorrectly. I wasn’t trying to suggest that the channel should be supported - I was just answering the question of where the channel came from in the first place.

This isn’t possible with configuration parameters (as far as I know).

JensH · February 10, 2019, 4:44pm

Thanks for fast answer, I‘ll calculate right values for it in rules then.

By the way: thanks for doing this job, programming and all the advice in the forum.

JensH · February 11, 2019, 6:44am

Hm, i got strange messages in log with setpont_surface, could it be there is some misspelling in the database? Setpont instead setpoint? Maybe it will work then if it’s only a missing i?

toffyrn · February 11, 2019, 12:19pm

Just tried 2.5.0~S1521-1, and I saw the same thing as you @JensH:

2019-02-11 12:40:37.622 [WARN ] [.ZWaveThermostatSetpointCommandClass] - Reached max tries to init the setpont Furnace, this will be our last attempt

The misspelling is in the logging, and is not the issue. I do not know why this WARN appears.

github.com

openhab/org.openhab.binding.zwave/blob/main/src/main/java/org/openhab/binding/zwave/internal/protocol/commandclass/ZWaveThermostatSetpointCommandClass.java#L417


      
              }
          
              public void setInitialised() {
                  initialised = true;
                  initCount = 0;
              }
          
              public boolean getInitialised() {
                  return initialised;
              }
          
              public void incrementInitCount() {
                  initCount++;
                  if (initCount >= MAX_DYNAMIC_TRIES) {
                      setInitialised();
                      logger.warn("Reached max tries to init the setpont {}, this will be our last attempt ",
                              setpointType.getLabel());
                  }
              }
          }

I did however face some other issues breaking my rules that I cannot resolve right now, so I downgraded openhab2 back to S1512, but left openhab2-addons at S1521. The warning is now gone. I assume (for now) this issue is unrelated to database.

Perhaps @chris can shed some light on this warning?

JensH · February 11, 2019, 1:09pm

How did you go back to stable 1512 without downgrading the bindings?

toffyrn · February 11, 2019, 1:24pm

Hmm. I did “apt-get install openhab2=2.5.0~S1512…”. Might there be a dependency so that also add-on downgraded? Will check.

Anyhow, the device should still use the newer database entry, as the database entry is only changed when adding thing.

mkaut · February 11, 2019, 2:53pm

That’s weird. I asked the producers (Thermofloor) about the setpoint value and got the following answer (my translation from Norwegian): “I do not know what “Setpoint furnace” means. I would guess this is what we call “Setpoint thermostat”. Must be what Openhab has chosen to call it.”

Michal

sihui · February 11, 2019, 3:18pm

You are on an old zwave binding, the channel got removed with that change … or you are on a recent snapshot and did not delete and readd the Thing.

JensH · February 11, 2019, 5:02pm

I wrote them a long mail yesterday, listing their failures in firmware:
Three modes should have three working setpoints.
While changing temperature on device (changing eco) there is no update of any setpoint, while changing comfort setpoint (setpoint_heating) gets sometimes an update, sometimes don’t.

Child lock not supported by zwave, brightness should get channels from them.

Let’s look, what they will answer me.

With Zwave in openhab i find out that Param9 and 10 only get an update when other Parameter changed.

toffyrn · February 11, 2019, 7:46pm

Setpoint furnace seems to be defined by ZWave standard by:

This mode is used to activate fans to circulate air and heating or cooling will be activated to
regulate the temperature at the Furnace (0x07) setpoint.

No idea how that fits the idea of a floor heating thermostat…

On the other hand, what do you use the setpoint cooling for?

chris · February 11, 2019, 8:06pm

Please provide a debug logfile - otherwise I can’t see what is happening.

This is pretty old code (ie from OH1) so I’m not really familiar with this command class (I have no thermostats).

toffyrn · February 11, 2019, 8:09pm

I will wait a bit before upgrading again, hoping that the other issues are resolved. If the warning is still there we can try looking at debug logs

JensH · February 12, 2019, 12:29am

Some floor heatings you can change mode and then cold water is send to cool the rooms. In this case, the Thermostat (mode cooling) opens if it s getting to warm.

But more important is a NO and NC change in parameters. But that’s no problem from openhab, it’s the problem of Thermofloor made a very pretty design, good physical stuff, a good menu on device and a very bad firmware for zwave.

The device only shows incl to confirm inclusion when using secure mode. Fully included the display shows error, if using insecure inclusion.
No idea how they got the certificate from zwave alliance.

Physical temperature change doesn’t send new temperature via zwave, so much bugs.

Will see what they answer.

mkaut · February 13, 2019, 9:31pm

I have updated to the latest snapshot of the Zwave binding (build 562 from Feb. 11), but still don’t see the channels, even after deleting and re-adding the thermostat (as a Thing).
I guess that I had not stressed enough that I was talking about v1 of the Thermostat, with firmware 1.92.
(I realize that the thread is about Z-TRM2fx - I tried to start a separate thread about 1.92 (Help with setup of Heatit thermostat (v. 1), firmware 1.92 on openHAB 2.4), but did not get any answer there…)

toffyrn · February 13, 2019, 9:56pm

Sorry, I did not catch that. I also have some of the Multireg/TF016, but they all run either FW 1.4 or 1.8, and for my use I see no point in upgrading.

mkaut · February 14, 2019, 8:03pm

I was tempted by the ability to see the on/off status; bought a cable from AliExpress for under $2 and it worked.
The problem is that v 1.92 does not work with openHAB properly. It lacks “setpoint eco” and instead has “setpoint furnace” that at least in my installation does not correspond to anything I can see on the thermostat. This means that I cannot control the setpoint in eco modus.
I am considering downgrading, if I find the 1.8 firmware somewhere…