Excellent update, @bangali!
One thing I noticed is that there is no wind
or feelsLike
entry in the attributesMap, so there's no way for the user to turn those on and thus they wont get published under the new sendEventPublish
approach.
I also posted that as a comment to your GitHub along with a request to distinguish the description of localSunrise
and local_sunrise
in the attributesMap as they both read as 'Local Sunrise' (same with the sunset).
--
I haven't tested to see if it's an issue here, but one thing I've run into in the past is that if a device is defined as including a certain capability, but it doesn't publish the attributes associated with that capability, it can cause Hubitat to hang when trying to introspect the attributes.
// For Example:
// If a device indicates that is has the 'Switch' capability
// but it never defines a 'switch' attribute
// then code like this can cause the hub to hang
device.supportedAttributes?.collect {[
name: it.name,
dataType: it.dataType,
values: it.values
]},
Again, I haven't run into this in a while, so I haven't tested it recently. Ideally the platform would be able to work around this without hanging, but it's something I wanted to throw out there since you are now defining capabilities like Temperature, Illuminance, Humidity, Pressure, and UV and users have the options of disabling the publishing of those attributes.
--
One other minor comment is that once an attribute is published, there doesn't seem to be a way to 'unpublish' it... so perhaps the first post could be updated to call this out as an important configuration step?
While unchecking the option for those attributes would at least reduce the events on the system, it still keeps the attribute defined on the device which increases the burden on apps / the hub when trying to iterate through properties of the device.
Again, awesome work on the updates! Keep up the good work!