Hello. I’m using Hass.io on an RPi 3B+ with quite a few various devices and automations working, with no functional problems. However, among my stuff I have 3 Visonic MCT-340 E Zigbee door/windows sensors. All 3 work properly in automations, and in Developer Tools > States all 3 indicate states of ‘off’ and ‘on’ as a binary sensor should. However, in the Lovelace UI for no reason I can find, one of the 3 (only 1) reports as a moisture sensor, i.e. my front door is shown as either ‘wet’ or ‘dry’. I’ve tried to override the device_class in customize.yaml, trying to change it from ‘moisture’ to both ‘opening’ and ‘door’, but the device_class reported in Developer Tools > States remains unchanged and continues to say ‘moisture’. Anyone got any thoughts on how I can change what shows up in the UI for this one sensor? And maybe on why, out of the box, this 1 is different from the other 2? All my reserch so far indicates the device_class should do it but I can’t seem to change it, nor do I know why it is using ‘moisture’ in the first place.
Thanks.
Jeff
Did you enable customize in configuration.yaml?
Can you please post the customize.yaml?
Did you also try changing it with the UI?
Hi. I have customize configured in configuration.yaml as part of the default configuration:
# Configure a default setup of Home Assistant (frontend, api, etc)
default_config:
If I try to include customize additionally and explicitely in configuration.yaml I get a config error about it and everything breaks.
I did try both direct editing and the UI to set up the customize.yaml file Below is when I do it via the UI.
binary_sensor.front_door_sensor:
device_class: opening
As an additional test, after I submitted my post, I changed the device_class for one of the other Visonic sensors, just to see what would happen. It changed how that device showed up in the UI immediately, but then it reverted back to its original appearance even though the customize.yaml change was still there. However the problematic sensor never changes, even for a short time. Seems like customize.yaml might not be working properly, although running the config checker shows no problems…
The ‘default_config’ part of my configuration.yaml file came from an article I followed a while ago when I first split my configuration into multiple files. That has been working fine for quite some time but tomorrow I think I’ll remove the ‘default_config’ and replace it with the individual elements that it covers, including an explicit reference to customize.yaml, and then I’ll see if that helps. This is the first time I’ve had to use customize.yaml.
Thanks.
Jeff
OK, looks like I’ve got it figured out. Simple and repeatd mistake on my part. The customization integration is not, after all, included in the default_config. However, the config error I kept seeing when explicitely adding customize.yaml to my configuration.yaml was not a result of a duplicate configuration, as I was thinking. Instead I just kept missing the fact that the ‘include’ statement for the customize.yaml file needed to be in a ‘homeassistant’ section in configuration.yaml rather than just on its own.
Still don’t know why that one sensor wants to be a moisture sensor instead of a door sensor like the other two of its type, but at least now my front door is open or closed instead of wet or dry.