Hubitat with Homemade Temperature, Humidity, Pressure and Light sensor

I have successfully reattached it. All is well. Now I am tweaking the zigbee reporting configuration parameters for each to suit my needs.

That is good idea. I am courious what you will come up with.

could you please multiply the illuminance by 100 or something and publish as an integer please. otherwise it just seems too low compared to other common light sensors around the house.

I have noticed something interesting regarding the illuminance reporting. It seems that if the iluminance goes from some value directly to 0, the sensor does not report the change in value until the maxReportTime value is exceeded. Every other change is reported properly at the minReportTime, assuming the change exceeds the reportableChange value.

Any thoughts? It is not really a problem as I can simply adjust the maxReportTime to a smaller value versus waiting 5 minutes to see the illuminance drop to zero.

One idea I have would be to modify the driver to add user preferences for the minReportTime, maxReportTime, and reportableChange for each sensor. This would make it easier for users to make changes and preserve these values when the driver code is upgraded. Also, adding an option for F to C would be nice for some users.

@bangali For illuminance conversion, I simply changed the code to be the following to get it scaled to approximately 0 to 10000 as an integer.

private def createIlluminanceEvent(int ilumm)
{
    def result = [:]
    result.name = "illuminance"
    result.translatable = true
    result.unit = "Lux"

    result.value = ((double) ilumm / 2.8).toInteger()

/*    if(ilumm == 0)
    {
        result.value = 0.0
    }
    else
    {
        result.value = (10.0 ** (((double) ilumm / 10000.0) -1.0)).round(2)
    }
*/
    result.descriptionText = "{{ device.displayName }} illuminance was $result.value"

    return result
}
1 Like

@iharyadi may be you could add this code from @ogiewon to the driver on github?

i could do it locally ... but likely this would be useful for everyone. :slight_smile:

I have not seen the behavior with 0 lux value. I will watch for it.

Zigbee reporting in my opinion should be adjusted based on the application. It is not a user setting. One application may want to read / report attribute one way. Other may want to read another way. One part of platform like ST and Hubitat, it allow developer to change it anyway the developer want it.

The F or C is ST or Hubitat option. If you look at the code, zigbee will report in celcius only. Somehow, ST and Hubitat display it in F. The only way for dth to control it is to make its own temperature custom capability.

1 Like

I can provide a preference to adjust the illuminance.

btw the sensor is now in garage ... where the garage door is closed and pretty dark but still reporting around 500 lux. may be needs some adjustment?

You can adjust the zigbee reporting. You can set the minimum value to 0.

If that still a problem, i would check if the packet is being dropped. To check this, you want to try move the sensor closer to hub temporarily and test with exposing the sensor with different light.

i just changed that line to:

result.value = (ilumm / 500d).toInteger()

now report 3 lux during day with garage door closed and 50 lux with the door open ... that is good for my purpose.

Hi Dan,

I have double check the issue "iluminance goes from some value directly to 0".

I have no issue here with my modules here. I also review the code. There is nothing that I can see that may cause this issue.

Possibly, it could be that the packet does not get to hub (packet loss). This could happen as zigbee is nothing like TCP/IP. When that packet loss, assuming the value of illuminate is in the range of reporting interval parameter, the next packet will be on the maxtimeout. In this case, your solution is correct. You can just reduce the maxTimeout to get faster update when this happen.

If you are in experimenting mode, you can try to move the sensor and hub closer. Then, repeat the experiment. If you are not having issue at closer distance, you may have packet loss issue. There are some way to optimize your connection by adjusting the sensor position. The PCB antenna like to be vertical. However, my opinion is to build denser zigbee network. I do have plenty of them in my house so that no matter how I position my sensor, I do not see too much of an issue. Hopefully, I will have some more sensor to share with you in the future.

1 Like

I went back and work on old unused prototype board. I hate to waste it. This time around I have separate sensor modules and wire it up to the module. I bought a Leviton USB outlet and did this.

Here is installation.

And, the finished project.

Somebody is really happy with it.

er ... is that like safe?

1 Like

I am not really messing around with the high voltage of the circuit.

This is more of learning for me at this moment. I am courious about the sensor performance with this setup.

Eventually, I think having the zigbee, sensor, usb chager and some sort of relay integrated in the outlet would be nice.

ok ... be safe.

1 Like

DH updated with illumination calculation per requested here.

There is a new preference for illuminance factor adjustment as with requested formula as follow.

result = (zigbee illuminance / factor).toInteger()

Valid value for the factor is number larger or equal to 1.

If it is empty, the illuminance value will be in double value. It will still be calculated per zigbee cluster standard. It is the original lux calculation which is significantly different from what is requested here.

DH is also updated with some clean up code. The Zigbee parsing between Hubitat and ST is quite different. I am able to remove a bunch of code in the case of Hubitat.

added a bunch of zigbee devices today ... its been a few hours and things look a bit different.

not so good i think? specially surprised at how high the packet drop is.

This is not the worst I have ever seen. I have a couple people at ST that has a lot higher. Just watch that number.

I have all of mine has 0 packet drop. Perhaps one or or two after one month of usage. I do not expect everyone has 0 packet drop. However, when I see number in the thausand, that is when I am worried.

In your case, I would double check your antenna there. Maybe there was something loose. Or perhaps play around with orientation.

BTW, I believe packet drop usually due to interference. Interference may cause corrupted packet, hence it will be dropped. However, some member mentioned about Sylvanias devices may be the cause. Can you help watch whether adding those devices cause this issue. If this is the case, I like to know which device cause the packet count to go up.

amongst the zigbee devices were a couple of Sylvania bulbs. I added them all back to back and have no way of telling if that caused the issue.

if it helps I can turn on debug logging for both those bulbs and the sensor ... collect 15 mins of log data and share that with you?