More fine grained way of hiding properties in devices

[hashat]

Currently there seems to be a way of hiding either

• entire devices, such as WH65, (with all properties), or
• classes of properties, such as humidity, (in all devices). Do I get this correctly?

Would there be a way to make this more fine-grained in case I want to hide humidity only in WH65? Use case: I have multiple devices measuring the same property, and I'd like to show only one of these in the Home app.

[hashat]

UPDATE: I just see this is a documentation / UI issue, because it is definitely possible to do it directly in the JSON config file:

"hidden": {
    "WH65:temperature": true,
    "WH65:humidity": true
},

However, it's also true that since currently there seems to be no way of setting this on the form-based config sheet, if someone alters anything there and the config gets re-generated based on the form, then this fine-grained setting will be lost.

[rhockenbury]

Hi @hashat. Thanks for reaching out. This is something that I struggled with, and went with an 80 / 20 solution. From the plugin config UI, you are correct that "hiding" is either a weather property across all devices, or a full specific accessory. As you pointed out, I left in the implementation for hiding a specific property on a specific device, but that can only be configured through the plugin json directly. This has the caveat that the user would have to only configure the plugin through the json config going forward or risk resetting values, and I chose not to document this capability for that reason.

I think this approach would be okay for most users, providing a UI-based way to hide things for most common use cases, but retaining more advanced functionality if needed (with the slight annoyance of working directly with the json config). Let me know your thoughts.

[hashat]

Agreed with your reasoning about the 80/20 solution now. Nevertheless let me point out some further considerations:

• On the short/mid term, I think that at least the documentation could be improved with your reasoning, explaining there exactly what you write above: One can set from the UI like this or that with such and such caveats, OR one can set it more fine-grained straight from the JSON (and give rough pointers how), but then must take care of never again running the UI, because of the risk of overwriting...
• On the mid term, further documentation improvement might be necessary, because unless one goes into the networking part to get the actual data reported by the Ecowitt GW, or one gets the internal debug data of your plugin God-knows-how (documentation), and/or one checks in the coding of the plugin from GitHub, I would not call it super-intuitive to find out how to rename/hide resources (what the properties are...). And I acknowledge the complexities of keeping the documentation vs the things-under-the-hood in sync.... but I'm offering my help here.
• On the long term, what can be done would be similar to how the homebridge-tado-platform-rf plugin solves the similar issue: It queries the service first, and then builds the config UI based on parameters that it finds (that make sense in the specific context to set). I agree that in the case of Ecowitt this has limitations, because (1) there's no service to query, because we're working based on fundamentally push/POST-type reporting so there's an inherent indeterminstic async-ness, with the added complexity of (2) properties reported might/will change over time...

Just typed these in because you asked for my thoughts :)

[rhockenbury]

Thanks for the feedback! Always appreciate it.

I'm aware that there's been confusion in getting the names of the properties for renaming so I definitely agree that more documentation around that would be a benefit.

I had briefly looked at doing a custom UI for the plugin which would would permit more flexibility. I can take a look at the example you mentioned to understand the LoE and see if the investment might be worth it.