Interview errors for ThermostatSetPoint Command Class with both GoControl thermostat and alarm.com thermostat

[PoltoS]

Please understand - the one particular device that I've seen logs from works with errors - this is a device bug and even if it shows something on other controllers, the device might have more issues and give you more problems in future. It is like a car with breaks problems. You can still drive it, but at some point it might bring troubles. And even if others reported that this car was able to cross a flat desert, it might fail for you in mountains.

I'm proposing to contact the manufacturer to make sure that they are aware, they know the issue and can check if this error affects other functions. This is my attitude/answer.

But may be there are more recent/old versions of this device without the issue above, so they will work - this is very common to have 3-5 different firmware and hardware revisions under the same SKU/part number. So may be your four are not affected.

Since we do not have those devices to test, we have to base ourself on logs. Based on logs we can make a hack to support this device, but not sure there are no other issues to solve. Best would be to get an answer from the manufacturer and solve it together.

[JasonJoel]

Thanks for the detailed response. I understand what you are saying. And I will say that maybe I was a little too aggressive in my tone.

I wrote a GoControl gc-tbz48 driver for 3 different platforms, so am especially familiar with how it works.

I'm not aware of any other firmware revs for the plus version. But maybe there is? Sometimes I don't know what I don't know, and all 4 of mine are the same firmware.

While I'm not as familiar with the requirements in z-way, I can say that no server side workarounds were required to use this device on any other platform I've used it on/wrote the driver for.

So I guess I'm just ignorant of why it would need a workaround in z-way.

[rafale77]

I will just be speculating a little here based one what I am reading from my thermostat's manual which is a different brand and model altogether (Remotec ZTS-500) and Z-way's manual appendix on command classes that Z-way's implementation for a lot of these thermostat command classes are much too restrictive. I have a number of mine interviewing correctly or not but still functioning on expertUI but not creating any vDev or moving any of them to SmarthomeUI. My issue is on the Thermostat Operating mode which, reports completely different data and serves a totally different purpose than what the Z-way manual states. Again, it still works: I can see the state change on expert UI when the operating state changes but Z-way expects some weird logging feature. You may have a similar problem with ThermostatSetPoint. I am not sure about the previous user's device but I would rather interpret the "corrupted" packets as "unknown" packets to z-way and something to look into. It goes back to my other thread about allowing users to override and assign CC to the smarthomeUI. All that is needed is for us to allow the thermostat vDev (ZAutomation API) to have these CC which are already present in ExpertUI (ZWaveAPI).