Fix for missing commands: anyone using the recent RGB functionality would need to 'repair' in HPM to get the fix.
I opened another PR to support sensors of unknown types. This can be used to handle generic sensors which have device classes or units that are not yet supported.
1 Like
Note to anyone using HPM, I accidentally left a few of the new child types off of the optional drivers list. So, be sure to use HPM to 'Repair' and 'Modify' if you want to add those (Carbon Dioxide, Radon, and Volatile Organic Compounds).
Big thanks to @mboisson for new features in versions 0.1.48 and 0.1.49.
- Those aforementioned environmental sensors were the main feature in 0.1.48.
- @mboisson added a cool new "Unknown" sensor type in 0.1.49, which will provide a basic level of support for anything in
device_classsensor that isn't fully support in HADB.
5 Likes
I like the idea to handle Unknown Devices! 
May I suggest a small addition?
Among other things I use the bridge to monitor the ink levels of my printer. But everytime the printer goes in sleep mode, Homeassistant sets all the attributes to 'unavailable'.
IMHO in this case it would be better to simple ignore this and just keep the "old" values...
Therefore I have modified the driver code of my local instance of "Generic Component Unknown Sensor" to optionally(!) solve this problem. Here are the changes I made:
preferences {
input name:'txtEnable', type:'bool', title:'Enable descriptionText logging', defaultValue:true
input name:'ignoreGlitches', type:'bool', title:'Ignore Glitches (UNAVAILABLE etc.)', defaultValue:false //JS20221206
}
void updateAttr(String aKey, aValue, String aUnit = ''){
if (ignoreGlitches && aValue in ['unknown', 'unavailable']) return //JS20221206
sendEvent(name:aKey, value:aValue, unit:aUnit)
}
With this changes (and with ignoreGlitches = true) the values are always available, independently from the wake state.
=> Even if the printer is sleeping, the correct ink levels are shown.
Please, could you add this to the official code?
May I point out that this unavailable status is return by HA for all entity type, not only unknown devices. Setting it to the last known state may result in inconstistencies. The state usually correct itself when the device becomes available again.
Is this causing problems with other type of sensors? If so, maybe it should be handled at another level.
1 Like
I agree. I don't think we want to start adding "special" logic to HADB to account for the behaviors in HA itself. It works really well as a pass-through of the events that come in, but if something like this needs to be filtered I would do it in the automation logic in RM or some other app that is using the device.
I agree with Jost that it would be nice to be able to filter values: i.e. don't update if it doesn't fit what is expected (for example a number).
Doing it in RM would mean creating other virtual devices that get updated based on the ones created by HADB and then update or not based on a filter, rather complex.
1 Like
Yes, I have had that happen with other types of sensors (thermostats).
As for implementation, maybe have, as an option, a list of "forbidden values", configurable on a per device basis or in the parent. If the received value is in that list, don't update. That list would be empty by default.
1 Like
I was thinking more that you would just trigger only on supported values (and others would be implicitly ignored). Which, in my mind means there is no reason to have an intermediary virtual device to track states. I guess this way works well for triggers in RM but maybe not so well for visible inspection of the data like in Dashboards.
Right, that does not work for dashboards. Also, if you set triggers in RM for "on change", then changing for unknown/unavailable is seen as a change and it triggers the rule. You can of course handle that in a rule, but if you integrate into other apps that you don't control (for example, I have the app AverageThis, to average noisy data, which would get triggered by that, and probably try to average "unknown"/"unavailable" and barf on that value).
Ultimately, the right behavior depends on context, but having the flexibility to do so in HADB would be handy.
2 Likes
Also, if you want to do a trigger on "attribute X becomes Y", then it will trigger multiple times if attribute X goes from Y to "unavailable" and back to "Y" (and back to "unavailable" and back to "Y", ...)., even though in reality it did not change multiple times.
I actually encountered that trying to automate events based on a notification. I had to use a virtual switch that just stays on if the value is "unavailable", as a mean to track the "clean value". Short of a filter in HADB, such situations can only be handled through some other mean of storing the value, an intermediate device/switch/variable that is clean, and then trigger on changes of that value, rather than the "dirty" value.
1 Like
I remember this was discussed in the early stage of developement and it was decided to live it but it doesn't mean it as to stay like this. In my opinion, Handling it at the component level is not ideal since HADB rely heavily on build-in components. Building lists of acceptable values for devices seems to me, quite an endeavor.
As far as I can see, HE deal with unavailability by doing nothing (witch amount to keed the last value). Maybe that would be the approach we should persue for all devices.
3 Likes
I haven't used much breadth of HA devices. Is there a finite list of "invalid" type of values that might be returned? If so, it may be possible to provide a filtering option at the parent driver level instead of in each child.
Just a thought, but it probably breaks down if random devices might have non-standard values that they return (which might last in a very long list of items to filter if a user has a large or mixed system).
I think "unavailable" is a standard state reported by HA when a device becomes unresponsive. This can be easily dealt with at the parent level. I doubt HA would return an invalid value (from the point of view of the device).
I don't know about "unknown" state. Does HA report that?
1 Like
I myself have only seen unavailable. In fact, I have one device which is currently cloud-based and fetched through Home Assistant to be fed into Hubitat through HADB and which I am working on writing a native Zigbee driver for Hubitat. It is currently disconnected from the other cloud-based platform and it reports its values as unavailable
1 Like
Maybe we should just filter that attribute value, regardless of the type of device, at the parent driver level. What do you think @ymerj?
1 Like
Is it possible that some attributes of a device report as unknown while others are valid (in the same event)? Or is it all or nothing?
Isn't it one event per attribute ?
