I dunno, i could try 59 sec and see if it changes from 2min to 1min.
Home assistant. ZwaveJS2MQTT add-on. Also when I change a config value, itāll then refresh to its previous one. Iāve found I had to āpingā the device, then change the value and it seems to stick. This is the first battery device ive changed values on, so maybe thats normal since the device is normally asleep?
Z-Wave sleepy devices only get config changes when they wake up and check in based on their wake up interval. The driver will direct the hub to send any configuration updates during the wake up period. In the meantime, some drivers will show you the ācurrentā configuration as to what the device last was set to, some will say that an update is pending, some will show what your latest requested configuration is, some will show a combo of all 3.
After you make a change, press the button on the back of the sensor 3x for force it to wake up. Once it wakes up, Zwavejs2mqtt will send it the updates.
Thanks for the reply. Like mentioned, maybe the config options havenāt taken. I tried both 60 seconds and 240 seconds and I was seeing what was expected.
Mine seems to be updating at correct intervals now. Maybe home assistant times were just off? I was timing it was stop watch and I now get 5 min intervals.
Is the only way to write new config values to the sensor via waking it up?
And is the only way to wake it up manually is by pressing the button 3x?
Iād like to only have motion enabled at night. But during the day, I want to turn it off so that I can save battery life.
It only updates the parameters when it wakes (either by manually waking with button 3x, or during the scheduled wakeup interval. You can change the wakeup interval with zwavejs2mqtt.
2 Likes
This very much. You can make all of the setting changes you want, but you have to wait until it wakes up to see and apply the setting changes for anything to actually change.
1 Like
I have had my 4 in 1 for about 3 weeks now, but I am having trouble getting it ādialed inā. I am really only interested in the light sensor portion of the device.
Initially put the unit in a South facing window. That seemed okay, until it was hit with direct sunlight and the reading in Hubitat read -23xxx lux. This negative value triggered the lights to come on at high noon. Not what I am after.
I moved the sensor out of direct sunlight, but now the lux level just seems to randomly bounce around hanging out in a range of 30-50 lux during the day, This narrow range makes it really hard to find a trigger number for turning lights on and off.
Is this thing working right? Should the lux value go negative under exposure to very bright sunlight?
The FW is 2.04
I did a Google search on the item above and found that someone raised this issue over on the Hubitat Community months ago. At the time, someone said there was a fix being issued, but I donāt think that fix got implemented.
I guess I can rule out bad hardware as there are others reporting the same behavior.
That was a Hubitat developer that said they were going to implement a fix on their side. I canāt get my sensor to report that āhighā, even in direct sunlight. So I canāt see the reports to see what is going on.
Iāve edited the driver to convert negative values to positive. Before updating can you post the logs that show what the sensor value report shows?
I went to the Hubitat board before this one and upgraded. I will try to downgrade the driver and get some numbers tomorrow. If we donāt have clouds.
I put the sensor outside my back door, itās barely 9 am so the sun is not all that strong yet. I managed to get it to go negative.
This system thinks that the logs are links and prevents me from pasting them hereā¦I donāt see a lot of loggingā¦but I have this.
dev:12502021-06-30 08:39:32.224 am infoLux Sensor: Illuminance report received: -9324
Can you paste then select preformatted text?
I have the update time set to 300 sec. This is even weirder than I thought. At 2 intervals the lux goes positive then flips back to negative again.
dev:12502021-06-30 09:19:32.327 am infoLux Sensor: Illuminance report received: -28712
dev:12502021-06-30 09:19:32.323 am debugLux Sensor: SensorMultilevelReport(precision:0, scale:1, sensorType:3, sensorValue:[143, 216], size:2, scaledSensorValue:-28712)
dev:12502021-06-30 09:14:32.347 am infoLux Sensor: Illuminance report received: -10715
dev:12502021-06-30 09:14:32.337 am debugLux Sensor: SensorMultilevelReport(precision:0, scale:1, sensorType:3, sensorValue:[214, 37], size:2, scaledSensorValue:-10715)
dev:12502021-06-30 09:09:32.291 am infoLux Sensor: Illuminance report received: 32445
dev:12502021-06-30 09:09:32.287 am debugLux Sensor: SensorMultilevelReport(precision:0, scale:1, sensorType:3, sensorValue:[126, 189], size:2, scaledSensorValue:32445)
dev:12502021-06-30 09:04:32.300 am infoLux Sensor: Illuminance report received: 31843
dev:12502021-06-30 09:04:32.295 am debugLux Sensor: SensorMultilevelReport(precision:0, scale:1, sensorType:3, sensorValue:[124, 99], size:2, scaledSensorValue:31843)
dev:12502021-06-30 08:59:32.372 am infoLux Sensor: Illuminance report received: -4059
dev:12502021-06-30 08:59:32.361 am debugLux Sensor: SensorMultilevelReport(precision:0, scale:1, sensorType:3, sensorValue:[240, 37], size:2, scaledSensorValue:-4059)
dev:12502021-06-30 08:54:32.309 am infoLux Sensor: Illuminance report received: -6478
dev:12502021-06-30 08:54:32.305 am debugLux Sensor: SensorMultilevelReport(precision:0, scale:1, sensorType:3, sensorValue:[230, 178], size:2, scaledSensorValue:-6478)
dev:12502021-06-30 08:49:32.375 am infoLux Sensor: Illuminance report received: -32739
dev:12502021-06-30 08:49:32.366 am debugLux Sensor: SensorMultilevelReport(precision:0, scale:1, sensorType:3, sensorValue:[128, 29], size:2, scaledSensorValue:-32739)
dev:12502021-06-30 08:44:32.266 am infoLux Sensor: Illuminance report received: -7725
dev:12502021-06-30 08:44:32.262 am debugLux Sensor: SensorMultilevelReport(precision:0, scale:1, sensorType:3, sensorValue:[225, 211], size:2, scaledSensorValue:-7725)
dev:12502021-06-30 08:39:32.224 am infoLux Sensor: Illuminance report received: -9324
dev:12502021-06-30 08:39:32.221 am debugLux Sensor: SensorMultilevelReport(precision:0, scale:1, sensorType:3, sensorValue:[219, 148], size:2, scaledSensorValue:-9324)
dev:12502021-06-30 08:38:07.510 am infoLux Sensor: If this sensor is battery powered, the configuration options (aside from temp, hum, & lum offsets) will not be updated until the sensor wakes up. To manually wake up the sensor, press the button on the back 3 times quickly.
dev:12502021-06-30 08:38:07.509 am infoLux Sensor: updated()
This is my understanding of the Illuminance Report:
| Field | Value | Meaning |
|---|---|---|
| Precision | 0 | Value has no decimal (a value of 123 means 123, not 12.3 or 1.23) |
| Scale | 1 | Means sensor value is in Lux |
| sensorType | 3 | Means sensor is measuring Illuminance |
| Size | 2 | Means sensor value is 2 bytes in length |
| sensorValue | [225, 211] | This is the actual value reported by the sensor (byte 1 = 255, byte 2 = 211) |
The problem is that the sensorValue is a signed 2-byte (16 bit) value with a range of -32768 to 32767. If we take the 2-byte sensorValue from the table above and convert it to an unsigned value, we get 57811. However, since 57811 outside the range of -32768 to 32767, it gets shown as a negative number.
According to wikipedia, a Lux value of 57811 is an acceptable value for an object in direct sunlight
I think the preferred solution would be for the sensor to send 4-byte values instead of 2-byte. This would require a change in firmware though.
The quick and dirty solution would be to convert the signed value to an unsigned value
I used this site to convert the values
Formula: ((sensorValue+32768) % 65536) + 32768 where ā%ā represents modular division
3 Likes
I am not sure this is allowed, but there is a thread on the Hubitat Community that I also have going about the mis-reported lux issue.
I am only technical enough to have some basic understanding of what is going on, but from what I am seeing, the workaround that has been put into place (driver converting negative nubmers to positive numbers) works, but the brightness levels displayed during times when the sensor is in direct sun are not accurate (non-linear).
The Hubitat people seem to be saying that the fault is in the device. Is this issue correctable via firmware or is this a limitation of the hardware itself?
The device is reporting a 2 byte signed value which (in this case) has negative values that represent positive ones. There just needs to be a conversion from signed to unsigned which I am working on.
Iāve put a new driver up that should fix this issue.
1 Like