I have several WindowCovering devices that have no need for a position indicating slider (there’s no position feedback from them at all). I’m trying to create a modified D_WindowCoveringX.JSON file which only has the other buttons. However, when I remove the JSON data for the slider only the buttons above where the slider appeared show up. The buttons defined below the slider no longer appear. My guess is that for a “device_type”: “urn:schemas-micasaverde-com:device:WindowCovering:1” the Vera code for some reason expects that slider to be there. Is that possible? I don’t think there’s any errors in the JSON file. It’s attached.
D_WindowCovering2.zip (1.6 KB)
Just from looking at the UI7 code (4903), it looks like a lot of the window covering UI is hard-coded. Not even sure what contribution the static JSON makes, there’s so much of it. And there’s even a spot where, like the thermostat debacle also being discussed this morning, there’s even a functional exception that’s driven by the name of the static JSON file. Why? Why…? This seems to be the theme of the day.
Edit: I tested your file on a Switchboard virtual covering, and I get the same results as you, which is what sent me looking at the UI7 JS code.
I have a workaround for this. I’ve discovered that if I set the device_type value in the JSON file to something other than urn:schemas-micasaverde-com:device:WindowCovering:1 the other buttons appear and work as intended. Right now I’m using “device_type”: “urn:schemas-micasaverde-com:device:GenericIO:1”
It’s a bit of a hack but it works. So far I’m not aware of any negative effects.
The only one is probably that mobile apps will stop displaying it properly.
My experience is that the mobile apps don’t use the static JSON for much of anything other than the state icons. If they did, our plugin UIs might be available. The mobile apps (including ImperiHome), seem to reply more on device type and category/subcategory. Sadly.
Correct. Changing the device type will usually break the display, since Json template is usually ignored. I hope they will change this in the next generation firmware and use a pure template-based definition language.
Hi,
What I did is make a small bit of logic in a I_WindowsCovering1.xml that simulates the positioning. I timed how long a full open/close take and based on that update the LoadLevelStatus. On the SetLoadLevelTarget I have the up/down command run based on the requested delta. So without a position feedback, the slider is still useful.
Cheers Rene
That’s interesting Rene. But I imagine that the LoadLevelStatus could easily get out of sync with the actual position when the user activates the up or down button followed by the stop button. Of course using the open or close button will get things back in sync.
For different kinds of window covers, how does a user set the full open/close time?
Hi tinman,
To get the timing for me it was just looking at my own installation using a timer. As in 90% of the times the setting is to full open or close (0 or 100%) you can reset the value based on that. For setting it half open, I am not to worried that letting it 50% ends up being 45 or 55. Having the option to set it to about half closed is more important in my situation.
Cheers Rene
OK, so you create a device variable to hold the time to fully open/close the window cover? And then manually set the value to what you measure? That seems to be a workable solution.