* AirVisual: Entity Registry updates and cleanup
* Small cleanup
* Owner-requested changes
* Changed hashing function
* Put a better class instatiation mechanism in place
* Small cleanup
* Reverting unintended breaking change
* Removing hashing as part of creating the unique ID
* Attempting to jumpstart Travis
Zigbee switches only contain client clusters that are meant to control server clusters on a different device/endpoint.
This device type -> cluster mapping can be found in https://www.nxp.com/docs/en/user-guide/JN-UG-3076.pdf.
The intended usage is of connecting client clusters to server clusters is described in https://products.currentbyge.com/sites/products.currentbyge.com/files/document_file/DT200-GE-Zigbee-Primer-Whitepaper.pdf
The lack of server clusters on switches has been verified using a GE ZigBee Lighting Switch 45856GE and a 45857GE dimmer.
Output from a 45856GE:
Device:
NWK: 0x0cd8
IEEE: 00:22:a3:00:00:1f:37:68
Endpoints:
1: profile=0x104, device_type=DeviceType.ON_OFF_LIGHT
Input Clusters:
Basic (0)
Identify (3)
Groups (4)
Scenes (5)
On/Off (6)
Metering (1794)
Diagnostic (2821)
Output Clusters:
Time (10)
Ota (25)
2: profile=0x104, device_type=DeviceType.ON_OFF_LIGHT_SWITCH
Input Clusters:
Basic (0)
Identify (3)
Diagnostic (2821)
Output Clusters:
Identify (3)
On/Off (6)
1. FanLincs have two nodes: one light and one fan motor. In order for each node to get detected as different Hass entity types, I removed the device-type check for FanLinc. The logic will now fall back on the uom checks which should work just fine. (An alternative approach here would be to special case FanLincs and handle them directly - but seeing as the newer 5.x ISY firmware already handles this much better using NodeDefs, I think this quick and dirty approach is fine for the older firmware.) Fixes#12030
2. Some non-dimming switches were appearing as `light`s in Hass due to an duplicate NodeDef being in the light domain filter. Removed! Fixes#12340
3. The `unqiue_id` property was throwing an error for certain entity types that don't have an `_id` property from the ISY. This issue has always been present, but was exposed by the entity registry which seems to be the first thing to actually try reading the `unique_id` property from the isy994 component.
* Checked file path with is_allowed_path() for RPi Camera
* Used cv.isfile to verify file path instead of manual checks
* Changed default file path for RPiCamera to config_dir/image.jpg
* Used tempfiles for storing RPi Camera images, if no other path is defined
* Stopped checking for whitelisted paths on temporary files
The yamaha component previously used a property named unique_id to
ensure that exactly 1 media_player was discovered per zone per
control_url. This was introduced so that hard coded devices wouldn't
be duplicated by automatically discovered devices.
In HA 0.63 unique_id became a reserved concept as part of the new
device registry, and the property was removed from the component. But
the default returns None, which had the side effect of only ever
registering a single unit + zone, the first one discovered. This was
typically the Main_Zone of the unit, but there is actually no
guaruntee of that.
This fix brings back the logic under a different property called
zone_id. This is not guarunteed to be globally stable like unique_id
is supposed to be, but it is suitable for the deduplication for yamaha
media players.
* Changed pyvera version to 0.2.41
Changed required pyvera version to 0.2.41 from 0.2.39.
The 0.2.41 supports the VeraSecure built in siren. Siren is treated as switch and can now be turned on and off. Before it was armable but generated error in Vera controller. This allows for both detecting status of Siren if triggered from within Vera and also outside controll from HA.
* Added pyvera 0.2.41 library
* Improve service by allowing to reference entity id instead of deconz id
* Change from having access to full entities to only store entity id together with deconz id
* Don't use eval, there is a dict type for voluptuous
* Use entity registry instead of keeping a local registry over entity ids
* Removed old code
* Add test for get_entry
* Bump dependency to v28
Fixed call to protected member
* Use chain to iterate over dict values
* Cleanup
* Fix hound comment
* Cleanup
* Follow refactoring of entity
* Revert to using a local registry
* Remove unused import
* self.hass is automatically available when entity is registered in hass
The yamaha component previously used a property named unique_id to
ensure that exactly 1 media_player was discovered per zone per
control_url. This was introduced so that hard coded devices wouldn't
be duplicated by automatically discovered devices.
In HA 0.63 unique_id became a reserved concept as part of the new
device registry, and the property was removed from the component. But
the default returns None, which had the side effect of only ever
registering a single unit + zone, the first one discovered. This was
typically the Main_Zone of the unit, but there is actually no
guaruntee of that.
This fix brings back the logic under a different property called
zone_id. This is not guarunteed to be globally stable like unique_id
is supposed to be, but it is suitable for the deduplication for yamaha
media players.
