Ah, I'm not quite as clever as I thought. Still not too bad to finish it up, and I'll contact you @SmartHomePrimer via PM to work it out.
Here is a Generic Component Illuminance driver I wrote a while back...
/*
Generic Component Illuminance Sensor
Copyright 2016, 2017, 2018, 2019 Hubitat Inc. All Rights Reserved
2019-02-23 2.1.10 Dan Ogorchock
-created illuminance sensor driver based on Hubitat's Dimmer example code
2019-09-07 2.1.5 maxwell
-refactor declarations
2018-12-15 maxwell
-initial pub
*/
metadata {
definition(name: "Generic Component Illuminance Sensor", namespace: "hubitat", author: "Dan Ogorchock", component: true) {
capability "Illuminance Measurement"
capability "Refresh"
}
preferences {
input name: "txtEnable", type: "bool", title: "Enable descriptionText logging", defaultValue: true
}
}
void updated() {
log.info "Updated..."
log.warn "description logging is: ${txtEnable == true}"
}
void installed() {
"Installed..."
device.updateSetting("txtEnable",[type:"bool",value:true])
refresh()
}
void parse(String description) { log.warn "parse(String description) not implemented" }
void parse(List<Map> description) {
description.each {
if (it.name in ["illuminance"]) {
if (txtEnable) log.info it.descriptionText
sendEvent(it)
}
}
}
void refresh() {
parent?.componentRefresh(this.device)
}
and here is a CO2 one...
/*
Generic Component Carbon Dioxide Sensor
Copyright 2016, 2017, 2018, 2019 Hubitat Inc. All Rights Reserved
2019-02-23 2.1.10 Dan Ogorchock
-created carbon dioxide sensor driver based on Hubitat's Dimmer example code
2019-09-07 2.1.5 maxwell
-refactor declarations
2018-12-15 maxwell
-initial pub
*/
metadata {
definition(name: "Generic Component Carbon Dioxide Sensor", namespace: "hubitat", author: "Dan Ogorchock", component: true) {
capability "Carbon Dioxide Measurement"
capability "Refresh"
}
preferences {
input name: "txtEnable", type: "bool", title: "Enable descriptionText logging", defaultValue: true
}
}
void updated() {
log.info "Updated..."
log.warn "description logging is: ${txtEnable == true}"
}
void installed() {
"Installed..."
device.updateSetting("txtEnable",[type:"bool",value:true])
refresh()
}
void parse(String description) { log.warn "parse(String description) not implemented" }
void parse(List<Map> description) {
description.each {
if (it.name in ["carbonDioxide"]) {
if (txtEnable) log.info it.descriptionText
sendEvent(it)
}
}
}
void refresh() {
parent?.componentRefresh(this.device)
}
I wrote these a while ago for another effort. Not sure how fully tested they are, but they are modelled after Mike Maxwell's example driver in the Hubitat public github repo. Feel free to use them as you see fit, @tomw.
Testing a pressure one as I type. My phone hasn't reported any changes yet. Will let you know if it updates correctly
/*
Copyright 2021
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-------------------------------------------
Change history:
0.1.13 - @tomw - initial version
*/
metadata
{
definition(name: "Generic Component Pressure Sensor", namespace: "community", author: "tomw", importUrl: "https://raw.githubusercontent.com/ymerj/HE-HA-control/main/genericComponentPressureSensor.groovy")
{
capability "PressureMeasurement"
}
preferences {
input name: "txtEnable", type: "bool", title: "Enable descriptionText logging", defaultValue: true
}
}
void updated() {
log.info "Updated..."
log.warn "description logging is: ${txtEnable == true}"
}
void installed() {
log.info "Installed..."
device.updateSetting("txtEnable",[type:"bool",value:true])
refresh()
}
void parse(String description) { log.warn "parse(String description) not implemented" }
void parse(List description) {
description.each {
if (it.name in ["pressure"]) {
if (txtEnable) log.info it.descriptionText
sendEvent(it)
}
}
}
void on() {
parent?.componentOn(this.device)
}
void off() {
parent?.componentOff(this.device)
}
void refresh() {
parent?.componentRefresh(this.device)
}
The on() and off() commands should be removed from that driver...
Lol...copy and paste baby!!
Shouldnt affect the test though.
@tomw, it worked. I got a pressure reading. Like @ogiewon mentioned, you should remove the on() and off() methods though.
Lol. It was off!
While looking at my logs I noticed one of my Hue lights went to "unavailable". Don't know why..my daughter probably hit the light switch...regardless, it's something you might need to account for in HE. Devices can report "unavailable" or "unknown".
Well this surprises me Stephan. White duct tape, itβs so cheap and easy to deploy!
Perfect. I just merged my changes to main on GitHub. Let me know if you guys see any other issues.
Lol...this switch is actually there for WAF. It's for my kitchen lights and I had the batteries die on my motion sensors a couple of times. My wife needs a manual way to turn these on at ALL times. Her words.
She Who Must Be Obeyed!
Will it be possible to set the children to go offline when there is no update for a given period of time? I'm thinking what @stephack suggested about "unavailable" or "unknown", but after a period, automatically disable them. Similar to the way it's done with Hub Mesh.
Excellent! The ability to specify the unit of measurement from the child at some point would be nice. Could be static for pressure as HA doesn't seem to change regardless of the Imperial or Metric setting. Always reports in Pascal (hPa)
I see there's already unavailable. This is a Sonoff Zigbee outlet that I have unplugged at the moment.
Yeah, I think the discussion is whether we should translate that to something. If there isn't a known value observed, like "on" or "off", what should happen? No update? Something else like "unavailable" or "n/a" (which might cause logic in rules to go haywire)?
My vote would be to trap invalid updates, and maybe simply log.info them. Those are not valid values for those attributes, and will just lead to confusion and/or issues with Hubitat Apps.
Might consider automatically disabling devices. I can see if you have hundreds of devices, you would have a hard time figuring out which is not reporting. But then again, if you have hundreds of devices you want in HE, you should be joining as many of them directly to HE as possible.
Not sure there is any way for the Parent device to do that... The Last Activity of the child device will show pretty clearly how long it has been since updates stopped being received. The parent device cannot simply remove the child device, as it may be in use by apps... This is really no different than a ZigBee/Z-Wave device's battery going dead. If the device is really important, the user will notice it. If not, it could go undetected for days/weeks/months...but it won't really hurt anything.
Good point. I have to throw ideas out there to know if their bad, otherwise their just ideas
I suppose @gopher.ny has the ability to automatically disable with Hub Mesh, but it's maybe not possible from a custom driver?