I’m going to propose that a new “Purpose” be implemented for cases where the Tile being added represents a Connector Variable device.
Maker API yields enough specific information to identify (a) that the device is a Connector, and (b) which type of Connector it is. Hence, HV ought to be able to parse that description in order to auto-select “VARIABLE” as a new Purpose, instead of relegating it to the current “Unknown?” catch-all.
The purpose is unclear for something like a connector - using the Tile Wizard would be an inappropriate use of the tool
I respectfully disagree, esp. since HE’s own dashboard app correctly identifies Variable Connectors and assigns them the correct template.
There are only a few VC types, some of which emulate a Virtual Device while others just provide the value of the Hub Var behind them. For example, a hub var of type NUMBER can be exposed to dashboards as any of the following device types:
Maker API spits out the connector’s type along with its other info:
Thus, the mapping is not only robust, it’s fully deterministic, so HV ought to be able to do what it already does with other device types, by assigning a suitable purpose.
In this case, the connector was assigned type HUMIDITY on the HE side, a perfectly valid device type for which HV should easily be able to assign a template.
You might be missing the point. Tile Wizard isn’t the right vehicle for creating a tile with no defined /specific purpose.
A connector device is a what? Switch? Light? Fan? A dice roll thingy? Unknown is still correct in the scheme of a Purpose for that type of device.
We may be perceiving Variable Connectors differently. To me, they are always a known entity (pass-thrus for first class Boolean, Number, DateTime, Decimal or String hub var … or one of the subclasses shown above).
As far as Tiles go, they’d correspond with displaying whatever value the ‘Variable’ attribute contains (if the former class), or acting like a virtual device (for the latter classes). So that, to me, would be their “purpose.”
I may have to draw up a table to demonstrate this better.
Sounds like they don’t have any specific purpose. I still don’t see any valid reason for including them in the Tile Wizard - what’s the specific setup step being done that isn’t just as easy doing it if Tile Wizard didn’t exist?? At best, they’d be a close cousin of a Sensor in terms of what you want it setup as
Lemme at least try including a few different Connector varieties as-is and see what Tile Wizard does with them. If one’s a “Dimmer”, I’d expect TW to treat it like a Dimmer, for instance. Stand by…
…RESULTS:
Tile Wizard assigns to → this Purpose
I also tested the BOOLEAN versions because they can take on a whole other set of guises (shown below):
For Bools, HV sees this → and assigns that purpose
FWIW that’s an exhaustive list. Nothing else lurking in the darkness.
@LibraSun it would be good if you could outline what you specific expect differently when you say “sensor but would be good it detected as contact” - so I’m clear, what specific difference would be on the tile vs if it left it as a sensor.
I think in almost all cases you’re just getting hung up on the name “sensor” or “unknown” when in fact there is probably no actual action you’d expect it to take differently
I’ll say again - you’re missing the point of the Tile Wizard, which is to fast track the setup of the tile for the typical purpose. A contact is essentially a sensor as they both have labels with attributes displayed - nothing more can be assumed
Will give it a deeper think in the AM, certainly.
Assessment complete. Before we continue, let’s get some terminology nailed down… so you know what I mean when I say…
“ATTRIBUTE” = any of a device’s self-reported attributes as relayed via Maker API (e.g. “LEVEL”, “SWITCH”, “MUTE”, “VOLUME”, etc.)
“CAPABILITY” = any of a device’s self-reported capabilities as relayed via Maker API (e.g. “SWITCH”, “SENSOR”, “ACTUATOR”, “DIMMER”, etc.)
“COMMAND” = any of a device’s self-reported allowed commands as relayed via Maker API (e.g. “PARSE”, “MUTE”, “ON”, “setVolume”, etc.)
“CONNECTOR” = one of 19 different virtual Device types – linked to Hub Variables on HE, since they cannot be exposed directly to Maker API – classified by datatype/devicetype (see table, below)
“DATATYPE” = one of Boolean, String, Number, Decimal or DateTime
“TYPE” = string value of ‘type’ parameter as returned by Maker API
(This is synonymous with “DEVICE TYPE” as selected in the HE UI.)
“TEMPLATE” = preset motif assigned by HV during Add Tile > Wizard, selected based on “TYPE”, if such a preset exists in hubiVue.
Table of possible TYPE values for Connectors:
NOTE: A checkmark denotes that a preset Template mapping exists.
BOOLEAN
Connector Contact Sensor
Connector Lock
Connector Motion Sensor
Connector Presence Sensor
Connector Switch
Connector Water Sensor
Connector Variable
DATETIME
Connector DateTime
Connector Variable
DECIMAL
Connector Temperature Sensor
Connector Variable
NUMBER
Connector Acceleration Sensor
Connector ColorTemp Control
Connector Dimmer
Connector Humidity Sensor
Connector Illuminance Sensor
Connector Volume Control
Connector Variable
STRING
Connector Variable
My “ask” here is that we create more Template mappings to accommodate more (if not all) of the possible Connector types.
EXISTING EXAMPLE
User adds a “Lock” device via Tile Wizard. HV establishes that ATTRIBUTES includes “Lock” and therefore assigns a preset Template denoting a “Lock”. The preset includes such aspects as:
and looks like this:
PROPOSED EXAMPLE
User adds a “Connector Lock” device via Tile Wizard. HV establishes that TYPE equals “Connector Lock” and therefore assigns a preset Template denoting a “Lock”. In all other ways identical to existing example, above.
And so on, with equivalent mappings for the various other CONNECTOR TYPES listed.
IMPORTANT
If this proposal is accepted, by extension the same accommodations should be made for TYPE = “Virtual Lock” (Tile Wizard already assigns “Lock” template to this particular type) and other Virtual Device equivalents. I have not tested all such mappings, so they may well currently exist.
Addressing this more directly, in the case of TYPE = CONNECTOR CONTACT, for which the possible Attribute states are “Open” and “Closed”, I’d want Tile Wizard to:
Sure, some users might wonder, “Why would you want controls on a sensor?” (As if a Sensor should be entirely passive.)
Answer: Use cases exist where you want manual control over contact closures, especially in situations (such as Amazon Alexa) where a Contact may initiate other routines. Voice assistant users are constantly having to dream up new ways to include devices in those ecosystems, that can act as Triggers. (Not all device types are permitted, you see, and only a small subset of those can act as triggers.)
Thus, I’m making the general argument that defaulting to Sensor – when further refinement is both possible and straightforward(?) to implement in Tile Wizard – places a sizable burden on HV users to “roll their own”. If HV could map more Connectors and Virtual Devices to known Device Types, hence to preset Templates, that becomes a value add for all involved, and goes beyond feature parity with other DB apps.
Which attracts more users. That, to me, is the ultimate goal here.
**nb. I cannot test what happens when an actual Contact is included with Maker API and HV, since I don’t happen to own such a physical device. I can only test with Virtual or Connector renditions of one.
Re reading the OP and you’ve moved considerably from the first post
Honestly, I really don’t know what you’re looking for…. I now think it’s saying…”I’ve found a case where a Virtual Lock’s purpose isn’t detected as correctly” but not really sure.
One thing is for sure, is that the Tile Wizard isn’t 100% complete and it will have gaps.
I think I’d drop focusing on Connectors and just focus on real / valid devices that have a purpose - and think along the lines of purposes, as that ensures the tile features are then correctly highlighted. Eg a contact sensor/device that you want to toggle some value is really a switch - it just has different on/off attributes to toggle and display
Yes. This. That’s what I’ve been trying to say all along. I may have hampered my initial posts on this topic by using the generic HE nomenclature “Variable Connectors” when I meant a whole class of potential virtual devices.
NOTE: More than half of my HV-exposed devices are Variable Connectors, many of them Boolean true/false that I use to arm/disarm automated workflows. I own precious few actual physical devices.
TileWizard works on Capabilities
If the device reports them, then it should work for similar devices that report them.
All of this looks correct to me.
So far, you’ve raised no issue but said a lot
So there’s still hope you’ll one day flesh out Tile Wizard to include pre-made Tile templates for (at least) Volume, Presence, Motion, and Contact (i.e. the ones that aren’t just pure “Sensors”)?
I don’t mind selecting those Purposes manually, but it sure would be nice if they existed. Otherwise, ya gotta do all the things from scratch, every time.
