altUI
-
I have one of these thermostats on Vera 3 and another on vera plus. For some reason they have different device_json and behave bit differently. Anything I can do to get them both on D_Heater1.json which suits me better than D_HeaterTempNoOnOff1.json as I don't need cooling? Have tried just replacing the text in Attributes but doesn't seem to save.
-
If you are doing this through the verabridge and reload luup, indeed it will go back to the same file being used by the vera. You need to change this field on the vera then luup reload both the vera and openLuup.
-
powisquarewrote on Mar 10, 2021, 10:32 PM last edited by powisquare Mar 10, 2021, 5:36 PM
Thank you - whereabouts in vera may I do this? Tried in device Params but doesn't seem to save. Do see 'Change property command sent' but after reload it reverts back.
-
Not sure why the vera would do this as you got the right place to make the change... and can't really help anymore since I have not followed the latest firmwares. I can only say that changing the device files used to work... Maybe try using ALTUI on the vera?
-
Unfortunately a lot of devices have hard coded settings, so you’ll loose changes after a reload. I’ve just added virtual devices to map them, in extreme situations (ie a security sensor mapped to a switch, or an heather mapped to a thermostat).
-
Seems odd that it's two different jsons for the same thermostat on separate veras. Perhaps the issue is inherently an altui one anyway. When I use the up down arrows for temp setpoint it starts from the cooling setting ie in this case 0 so its a lot of clicking to get to 20.
The same model thermostat paired to zway displays and behaves correctly with no cooling temps.
But they have the same json?
-
If they're on two different Veras are you sure that the file is not different on each?
Also I can't help but notice they have different category numbers. That made a difference on some Vera devices.
C
-
Sorry I was conflating issues. I have (a) two thermostats on separate veras that have different jsons and (b) one of those thermostats is shown above has the same json as another thermostat (on zway) but different functionality. Kinda got that muddled.
-
I think it depends on the different command classes that the device, but I could well be very wrong!
C
-
@powisquare as you can see, category and subcategory num are not set correctly. Try to set them the same (5, 1).
-
Can i set them to (0,0) as the (5,1) misbehaves?
-
@powisquare Try it!
-
Thanks - will have to try tomorrow - can't risk sending vera in to a tiz with guests staying.
-
@powisquare also, look at variables and post them here. Sometimes it's just some variable missing and creating it by hand will surely help.
-
toggledbitswrote on Mar 11, 2021, 1:08 PM last edited by toggledbits Mar 11, 2021, 8:10 AM
A lot of the functionality of thermostats is not in the static JSON files, it's actually hardcoded in UI7's interface.js and view.js files. This has been one of my issues with AVT and other thermostat plugins I've tried to do using the standard device types. The UI is so overloaded with kludges and exceptions for devices they specifically support (from Vera) that the generic device type is all but unusable. As I've groused about often in the other forums, they have a hellish mix of "methods" they've used over the years to try to express the capabilities and limitations of the devices, including magic values in state variables (which I think had the best possibility of success had they stuck with it and fixed what they didn't get on the first try, and documented it properly) and then worst... using the actual filename of the static JSON file (not its contents, where you could put anything you want, really) to determine capabilities. It's a mess.
-
True. AltUI adds another layer of this, because heaters got really supported only in recent builds.
-
May well be different machines, differing firmwares. Frustrating nevertheless. Here's a stab at displaying variables.
-
well, the one with HeaterTempNoOnOff.json is surely using a different json file, but setpoints seem to be OK. I'll take a deeper look lately.
-
... Keeping the device support at the command class level for z-wave devices like what z-way does is really much cleaner... What a mess. I had forgotten all about it. As you can see from @CatmanV2, that's all that was needed. If the command classes are recognized and bridged, it will work. It makes it almost impossible to not support a device. huh... to whom have I suggested to do that a long time ago in a galaxy far far away.... I wonder.
-
This post is deleted!
46/59
