ad-qolsys
ad-qolsys copied to clipboard
roopesh
Fix MQTT sensor discovery device_class
I have a test IQP2+ with 7 configured sensors, and 3 of them are generating errors when HA auto-discovers them due to the fact that the device_class is empty. There should be a "catch-all" value in device_class_mapping in qolsys_requests.py to ensure that device_class is defined with an appropriate value for proper discovery.
The 3 sensor types that don't work in my case are "Panel Glass Break", "Doorbell" and "Panel Motion". However, there are others that may not be explicitly defined so the catch-all rule should cover them all.
Error messages from HA are as follows:
2021-10-25 15:53:39 ERROR (MainThread) [homeassistant.util.logging] Exception in async_discover when dispatching 'mqtt_discovery_new_binary_sensor_mqtt': ({'name': 'Panel Glass Break', 'device_class': '', 'state_topic': 'mqtt-states/binary_sensor/panel_glass_break/state', 'payload_on': 'Open', 'payload_off': 'Closed', 'availability_mode': 'all', 'availability': [{'payload_available': 'online', 'payload_not_available': 'offline', 'topic': 'mqtt-availability/binary_sensor/panel_glass_break/availability'}, {'payload_available': 'online', 'payload_not_available': 'appdaemon/status', 'topic': 'appdaemon/status'}], 'platform': 'mqtt'},) Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/mqtt/mixins.py", line 180, in async_discover config = schema(discovery_payload) File "/usr/local/lib/python3.9/site-packages/voluptuous/schema_builder.py", line 272, in __call__ return self._compiled([], data) File "/usr/local/lib/python3.9/site-packages/voluptuous/schema_builder.py", line 594, in validate_dict return base_validate(path, iteritems(data), out) File "/usr/local/lib/python3.9/site-packages/voluptuous/schema_builder.py", line 432, in validate_mapping raise er.MultipleInvalid(errors) voluptuous.error.MultipleInvalid: value must be one of ['battery', 'battery_charging', 'cold', 'connectivity', 'door', 'garage_door', 'gas', 'heat', 'light', 'lock', 'moisture', 'motion', 'moving', 'occupancy', 'opening', 'plug', 'power', 'presence', 'problem', 'safety', 'smoke', 'sound', 'update', 'vibration', 'window'] for dictionary value @ data['device_class']
The list of valid device classes comes from Home Assistant. I would have to get your INFO message response to map in the various sensor types.
On Mon, Oct 25, 2021 at 1:11 PM jsb5151 @.***> wrote:
I have a test IQP2+ with 7 configured sensors, and 3 of them are generating errors when HA auto-discovers them due to the fact that the device_class is empty. There should be a "catch-all" value in device_class_mapping in qolsys_requests.py to ensure that device_class is defined with an appropriate value for proper discovery.
The 3 sensor types that don't work in my case are "Panel Glass Break", "Doorbell" and "Panel Motion". However, there are others that may not be explicitly defined so the catch-all rule should cover them all.
Error messages from HA are as follows:
2021-10-25 15:53:39 ERROR (MainThread) [homeassistant.util.logging] Exception in async_discover when dispatching 'mqtt_discovery_new_binary_sensor_mqtt': ({'name': 'Panel Glass Break', 'device_class': '', 'state_topic': 'mqtt-states/binary_sensor/panel_glass_break/state', 'payload_on': 'Open', 'payload_off': 'Closed', 'availability_mode': 'all', 'availability': [{'payload_available': 'online', 'payload_not_available': 'offline', 'topic': 'mqtt-availability/binary_sensor/panel_glass_break/availability'}, {'payload_available': 'online', 'payload_not_available': 'appdaemon/status', 'topic': 'appdaemon/status'}], 'platform': 'mqtt'},) Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/mqtt/mixins.py", line 180, in async_discover config = schema(discovery_payload) File "/usr/local/lib/python3.9/site-packages/voluptuous/schema_builder.py", line 272, in call return self._compiled([], data) File "/usr/local/lib/python3.9/site-packages/voluptuous/schema_builder.py", line 594, in validate_dict return base_validate(path, iteritems(data), out) File "/usr/local/lib/python3.9/site-packages/voluptuous/schema_builder.py", line 432, in validate_mapping raise er.MultipleInvalid(errors) voluptuous.error.MultipleInvalid: value must be one of ['battery', 'battery_charging', 'cold', 'connectivity', 'door', 'garage_door', 'gas', 'heat', 'light', 'lock', 'moisture', 'motion', 'moving', 'occupancy', 'opening', 'plug', 'power', 'presence', 'problem', 'safety', 'smoke', 'sound', 'update', 'vibration', 'window'] for dictionary value @ data['device_class']
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/roopesh/ad-qolsys/issues/21, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXEKH5KTQC5NT27KU2DV3UIW2WFANCNFSM5GWDSKOA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
That's true, but a good way to avoid that bug is to map a "default" device_class if the reported INFO message "type" field is not listed.
FYI, known sensor types & values are defined as follows: "type" = "zone_type" CONTACT = 1 MOTION = 2 SOUND = 3 BREAKAGE = 4 SMOKE_HEAT = 5 CARBON_MONOXIDE = 6 RADON = 7 TEMPERATURE = 8 PANIC_BUTTON = 9 CONTROL = 10 CAMERA = 11 LIGHT = 12 GPS = 13 SIREN = 14 WATER = 15 TILT = 16 FREEZE = 17 TAKEOVER_MODULE = 18 GLASSBREAK = 19 TRANSLATOR = 20 MEDICAL_PENDANT = 21 WATER_IQ_FLOOD = 22 WATER_OTHER_FLOOD = 23 IMAGE_SENSOR = 30 WIRED_SENSOR = 100 RF_SENSOR = 101 KEYFOB = 102 WALLFOB = 103 RF_KEYPAD = 104 PANEL = 105 WTTS_OR_SECONDARY = 106 SHOCK = 107 SHOCK_SENSOR_MULTI_FUNCTION = 108 DOOR_BELL = 109 CONTACT_MULTI_FUNCTION = 110 SMOKE_MULTI_FUNCTION = 111 TEMPERATURE_MULTI_FUNCTION = 112 SHOCK_OTHERS = 113 OCCUPANCY_SENSOR = 114 BLUETOOTH = 115 PANEL_GLASS_BREAK = 116 POWERG_SIREN = 117 BLUETOOTH_SPEAKER = 118 PANEL_MOTION = 119 ZWAVE_SIREN = 120 COUNT = 121
Happy to accept a PR mapping all those sensor types :)
On Mon, Oct 25, 2021 at 1:24 PM jsb5151 @.***> wrote:
That's true, but a good way to avoid that bug is to map a "default" device_class if the reported INFO message "type" field is not listed.
FYI, known sensor types & values are defined as follows: "type" = "zone_type" CONTACT = 1 MOTION = 2 SOUND = 3 BREAKAGE = 4 SMOKE_HEAT = 5 CARBON_MONOXIDE = 6 RADON = 7 TEMPERATURE = 8 PANIC_BUTTON = 9 CONTROL = 10 CAMERA = 11 LIGHT = 12 GPS = 13 SIREN = 14 WATER = 15 TILT = 16 FREEZE = 17 TAKEOVER_MODULE = 18 GLASSBREAK = 19 TRANSLATOR = 20 MEDICAL_PENDANT = 21 WATER_IQ_FLOOD = 22 WATER_OTHER_FLOOD = 23 IMAGE_SENSOR = 30 WIRED_SENSOR = 100 RF_SENSOR = 101 KEYFOB = 102 WALLFOB = 103 RF_KEYPAD = 104 PANEL = 105 WTTS_OR_SECONDARY = 106 SHOCK = 107 SHOCK_SENSOR_MULTI_FUNCTION = 108 DOOR_BELL = 109 CONTACT_MULTI_FUNCTION = 110 SMOKE_MULTI_FUNCTION = 111 TEMPERATURE_MULTI_FUNCTION = 112 SHOCK_OTHERS = 113 OCCUPANCY_SENSOR = 114 BLUETOOTH = 115 PANEL_GLASS_BREAK = 116 POWERG_SIREN = 117 BLUETOOTH_SPEAKER = 118 PANEL_MOTION = 119 ZWAVE_SIREN = 120 COUNT = 121
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/roopesh/ad-qolsys/issues/21#issuecomment-951289873, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXEKGMPYIYIK2654BRL7DUIW4JRANCNFSM5GWDSKOA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
I can work on it when I have a few minutes, but not sure how to properly implement an "any other sensor" type of catch-all. I'm asking because I know Qolsys likes to add new sensor types in new FW releases, as they seem to like adding new compatible PowerG devices :)
@roopesh @jsb5151 - I've got a PR in the works for that and just testing it out now. The mapping between qolsys and HA binary sensors isn't 100% compatible so something like vibration is a better fit for glass break and shock sensors etc. Also things like Keyfob, Keypad, GPS, etc are meaningless when mapped to binary sensors.
@Pablo1 - true. I'm testing some code here that makes unknown sensors default to "safety" so they show up in discovery. I'll submit a PR if that works.
@roopesh When do you think you'll be able to merge this pull request (as well as the other one). Anything we can do to help ?