Lux reading on two devices dropping out

I’ve got two motion control devices that include light sensing/measuring, a Dome (DMMS1) and a HAOZEE Zwave PIR Motion Sensor,Temperature, Light Sensor. They appear to be physically the same device, just the mounting is different.
I use them to monitor how bright it is outside and run scenes with LUA depending on their readings.
For some reason, the LUX reading on both the devices drops to zero occasionally (during the day). Haven’t been able to trace this to any particular time or scene action.
What I have noticed on the HAOZEE, if motion is detected, then the LUX reading from the unit comes back. The Dome does not exhibit this same action.

Both the units react properly to the motion detector aspect, the HAOZEE device also report its temperature, which also continues to report while the LUX reports zero.

So, any ideas/help on getting these two devices to report consistently? BTW, both batteries are slightly over 3V (CR123A)

thanks

This sounds like the HAOZEE has a firmware issue in how it reports the Lux value. (Most likely) or the vera is misinterpreting a command class into the luminosity variable (less likely since your have another sensor which doesn’t do that)

One idea would be to embed in your scene a logic which would store and check the previous value and to ignore the 0 value if the previous value was higher than a threshold… Maybe even to update the variable to the previous in this particular case.
It would be a patch to a defective firmware… not sure if your device has any update available since this seems pretty gross.

Rafael,

I guess I didn’t make myself clear, this happens with BOTH the units, not just the HAOZEE, though the HAOZEE LUX level was restored once I tripped the motion detector aspect (at least it restored it this morning when I checked it.)

Now, both units are once again reporting properly. Dang these intermittent problems!

I like the idea of imbedding the value, but the scene runs 4 times during the afternoon. I’m not sure how to imbed a value in the LUA code that would “keep” until the next time the scene runs.

I see… I have two ideas/directions to offer and they are very different.

First, I have had similar, though not identical problems where I had motion sensors having ghost trips which I correlated to battery level changes. This made no sense and I took as a bug in the vera misinterpreting a command class. I also initially blamed the sensor and swapped it out… same problem occurred on other sensors… Now this problem disappeared and I was to use that old ghostly sensor again… And I found was related to my zwave network being overwhelmed at certain times so I would recommend you look at this.

The other direction, if your sensor is really sending this 0 value through that command class, is to patch your scene with what I suggested. You can store the previous value as a variable in your device and then run a lua code to compare the new vs. old value. I recommend you look at the first approach first as I think it is the more likely problem. If it doesn’t fix it, I can help with the lua code.

Rafale

Don’t know how large a large system is, but I’ve got around 45 devices.

I’ll set the wakeup internals to 86400 as you suggested in the article. I’ll see what happens. Maybe I’ll set all my battery devices to do this.

I’ll keep you posted, thanks for your insight!

Brian

As I am discovering, a large network for vera is anything beyond maybe a dozen of devices. Especially if you have battery operated devices. 45 nodes is already beyond when I started seeing problems with default settings.

Wow, I didn’t think my system was that big, but I guess the devices crept in without my noticing the complexity growth.

I went into my devices and examined all my battery devices, other than the the two in question and set them to the 86400 wakeup interval. A number of them (I have 11) were already set to 43200. I’m not clear on why this should only be done to the battery devices (other than to save battery). It seems to me that vera polling devices should be the same and each would take up the same amount of bandwidth, whether they are battery or powered devices. Am I missing something?

I did look to the times of my scenes and a number of them are concentrated noon. This is when I noticed the lux readings dropped to zero.

Not sure if this impacts things but these scenes all have 90-120 second delay commands, ie, the scene does a luup.call_delay, then waits 30 seconds and does a second luup.call_delay, and on until all the luup calls are done, sometimes 5 in a scene.

If the system is so complex that it no longer works reliably, then I have a problem! Any insight into what might be coming down the pike from Vera/Ezlo that would me more robust?

I don’t think your scenes are too complex or should be a problem for the vera. The problem as I explained is the excessive overhead traffic vera has setup, I am speculating, in an effort to make the system more user friendly and accessible to less informed and wider public. It was a miserable failure because loading up in overhead was not the right compromise to make.

As for your question on the polling and wakeup, I would suggest to read my post in details. Wakeup only applies to battery operated devices. AC powered devices don’t wake up. They are always on… In that case the vera sets the polling interval on its own and I recommend to disable that completely.

Well, unfortunately, your suggestion about disabling polling on AC powered devices and setting the wakeup interval on the battery units to one day did not resolve my issues. The two units again last night started showing 0 Lux (and yes, I had lights on them).
This morning, the units are again reporting LUX levels consistent with what I see outside.

Last night the DOME unit was responding with a single blink when the motion detector was activated, but the scene associated with that did not run. This while Vera showed zero Lux.

So, as I see it, there are three possibilities, something is causing these two units to either not report to Vera correctly, something is causing Vera to not interpret the information from the units correctly, or both units are funky.

I understand your last suggestion about storing the last value and comparing it to the current one, but I’d rather resolve the underlying issue.

I would agree with you. I think it is too consistent and repeatable to be a network fluke and it is likely the sensors either firmware bug or defective…

I’m not sure it’s consistent - happens at different times of the day, sometimes it’s one unit, sometimes it’s both.
I’m not sure it’s repeatable, meaning it seems nothing I can directly toto cause this to happen. The problem does repeat itself however.
I’ll put in a call to Vera and see if they can see anything untoward in my unit and it’s actions. I’ll let you know what they find out.
Thanks again for your help. You do a great service to all us Vera non-tech users. I sure hope Vera is listening and taking to heart all that you’ve discovered.

1 Like

An update on my two devices - Spoke with Vera support, they suggested that I decrease the value that would trigger an update from the device to Vera.

In my case both the two light sensors had a level of 100 lux change before they would report into Vera. That seemed reasonable seeing as how the reporting range is from 0 in complete darkness to over 12000 lux in direct sunlight.

The tech said to set the value at 20. Since I made the change to 20, both sensors are reporting correctly. With no drop outs that I can tell.

So I’m keeping my fingers crossed.

Can you share the specific setting you changed? I am having the same issue and I don’t see any variable configured with a setting of 100 in my HAOZEE lux sensor.

Seth, you have to go to the parent device of the Lux Sensor device, then go to Device Options, then add a new Configuration Setting, #9. Which, according to the Hazoee User Manual, is the variable that sets the “Ambient illumination Lux Level Differential Report”.
Using the 1 byte dec format, put the number 20 in the desired value column.
Save the changes and exit out. Either wait for the unit to update itself, or press the “Code Button” inside the device to wake it up and update.
Hope it helps. The drop outs, while not gone altogether, at least they are few and far between (days).

You are a lifesaver! I called Vera support before posting and they had me change the poll interval. All that did was report 0 values more frequently. I have 3 of these devices now in my sunroom controlling 3 sets of motorized blinds. I still have issues with it reporting zero (about 90% less than before) but I think I may have figured out why. I was doing stuff on vera and it did a luup reload. When it did this one sensor was in direct sunlight reading like 13000lux. After the reload it was 0lux. the sensor stayed in direct sunlight for about 90 minutes. When the lux reading changed, Vera received the new value and all was well. During this time I was getting temp updates from the device regularly as it was getting warmer. So I know its not a comms issue. I think that since the lux value didn’t change, the sensor did not send an update to vera.

The problem is that any value of 0 will screw up scenes. So I came up with a workaround. I use PLEG for my advanced scenes and what I did was to start each condition with:
cLuxSensorDeviceProperty>0(Other conditions. . . … . . … )

This way the condition is only evaluated when the value is greater than 0. If it drops to 0 suddenly it will basically skip that reading and go on the last good value that it had. The setting you suggested made it MUCH better but this builds in kind of a failsafe.

Thanks again.