Cannot cast object 'null' with class 'null' to class 'int'
Closed this issue · 10 comments
This device seems to work relatively well with the driver:
https://www.aliexpress.com/item/3256803948188193.html
Advertised as a 2-in-1 motion sensor, I can see the model match as TS0601
endpointId: 01
model: TS0601
application: 40
manufacturer: _TZE200_3towulqd
Setting the Motion Keep Time to 10 for the TS0601 device is throwing an error in the log:
[dev:410]2022-09-19 09:27:21.828 pm [error]org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'null' with class 'null' to class 'int'. Try 'java.lang.Integer' instead on line 1089 (method updated)
30/60/120 options work fine, output from 120:
[dev:410]2022-09-19 09:33:57.526 pm [debug]AAAA sendZigbeeCommands (cmd=[he cmd 0xD3D8 0x01 0xEF00 0x00 {00090904000400000002}, delay 2000, he cmd 0xD3D8 0x01 0xEF00 0x00 {000A0A04000400000002}, delay 2000])
[dev:410]2022-09-19 09:33:57.523 pm [debug]AAAA sending the changed AdvancedOptions
[dev:410]2022-09-19 09:33:57.519 pm [warn]AAAA changing TS0601 Keep Time to : 2
[dev:410]2022-09-19 09:33:57.516 pm [debug]AAAA sendTuyaCommand = [he cmd 0xD3D8 0x01 0xEF00 0x00 {000A0A04000400000002}, delay 2000]
[dev:410]2022-09-19 09:33:57.512 pm [warn]AAAA changing TS0601 sensitivity to : 2
[dev:410]2022-09-19 09:33:57.509 pm [debug]AAAA sendTuyaCommand = [he cmd 0xD3D8 0x01 0xEF00 0x00 {00090904000400000002}, delay 2000]
[dev:410]2022-09-19 09:33:57.506 pm [debug]AAAA Config parameters changed! old=2424320943d37f1d8144bd new=2424320943d37f1d8142bd
[dev:410]2022-09-19 09:33:57.498 pm [info]AAAA Debug logging is will be turned off after 24 hours
[dev:410]2022-09-19 09:33:57.474 pm [info]AAAA Debug logging is true; Description text logging is true
[dev:410]2022-09-19 09:33:57.470 pm [info]AAAA Updating AAAA (Tuya Multi Sensor 4 In 1) model TS0601 manufacturer _TZE200_3towulqd
_TZE200_3towulqd
Thank you for the report, I will check and fix the 'Motion Keep Time = 10 seconds' exception in the driver; 10 seconds shouldn't be allowed for this type of sensor.
This TS0601 2-in-1 has such a long delay in reporting motion. Oddly enough, I can see debug lux activity when there is movement. I haven't made it reliably trigger yet, but when parsing the lux message I also call handleMotion(motionActive=true) to circumvent the keeptime minimum of 30s. Im trying to use the sensor to trigger lighting and ideally need to drop the response time below a second. If you are open to changes, I can dump them onto a branch for your approval. I was going to add this workaround as a slider enable/disable in the advanced options 'trigger on lux' or something.
I'm new to groovy, and have been toying with the language in my local driver. Not sure if a map lookup will break null checks.
@field static final Map sensitivityLevels = [ 0 : "low", 1 : "medium", 2 : "high" ]
@field static final Map keepTimeOptions = [ 0 : "30", 1 : "60", 2 : "120", 3 : "240" ]
@field static final Map keepTimeOptions_TS0601 = [ 0 : "10", 1 : "30", 2 : "60", 3 : "120" ]
...
def getSensitivityString( value ) { return sensitivityLevels.find{it.key == value}.value }
def getSensitivityValue( str ) { return sensitivityLevels.find{it.value == str}.key }
def getKeepTimeString( value ) {
if (is2in1()) {
return keepTimeOptions_TS0601.find{it.key == value}.value
}
return keepTimeOptions.find{it.key == value}.value
}
def getKeepTimeValue( str ) {
if (is2in1()) {
return keepTimeOptions_TS0601.find{it.value == str}.key
}
return keepTimeOptions.find{it.value == str}.key
}
How do you determine the valid keeptime options?
Hay @matt-r-chan ,
I will be happy to merge your changes into this driver! You can send a Pull Request, or just provide me a cloud link containing your branch and I can do the merge.
I am rather busy this week but will have the time to dig deeper into this sensor specifics during the weekend.
This TS0601 2-in-1 has such a long delay in reporting motion. Oddly enough, I can see debug lux activity when there is movement.
This is rather odd... Usually, these cheap sensors report first the motion, and then very quickly, and only after the motion event report the illuminance.
I also call
handleMotion(motionActive=true)to circumvent the keeptime minimum of 30s.
This doesn't sound right, except this thing is really sending the lux reading first, which will be very weird.
Have you added this device fingerprint to your driver and then pair again it again to HE hub?
The strange behavior that you describe may be due to the IAS enroll procedure not being completed successfully.
How do you determine the valid keeptime options?
I usually start searching in Github for the unique device Manufacturer ID. A qauick search of '_TZE200_3towulqd' reveals that it is already supported in Z2M. Results also show that my previous assumption that 10 seconds retrigger time is not a valid setting for this device was probably wrong. So a keep time ENUM value of 0 should mean 10 seconds retrigger period for your device.
Great tip about searching github.
Shoot, I don't think my solution of keying off the lux message is stable. I am seeing false positives without any motion in the area. Im using it to safely light up dark steps, so I can accept the false positives for now
I have 6 of these, and I have deployed 3 so far. They seem to behave slightly different from each other. There is a red glow on one of the sensors during motion. One only ever reports lux. One is pretty solid.
I was reading the comments at https://www.aliexpress.com/item/1005004095233195.html and some of the customers also complained about the delay in motion reporting (half to one second, compared to other PIR sensors).
The one sensor that is working OK with your setup - which event comes first: the motion or the illuminance? What is the delay between the two events?
Have in mind these ÁliExpres 'specifics :) ' :
- often the batteries that come with the cheap sensors are of a very low quality. You may still measure 3V with an high impedance voltmeter, but the crappy battery internal resistance is so high, so that when the device starts to transmit the Zigbee messages (especially during the intensive communication when paired to the hub) the voltage drops and the device may be reset or the transmission to be corrupted. Replace the cell battery with a new one while pairing the sensor to the hub.
- check whether the battery holder metal plates make good contact to the cell. Bend them a little if needed.
- always pair the sensors very close to the hub. If the pairing is successful, you can move it later to the final destination, then press shortly the pair button and the device will quickly find a Zigbee repeater if needed. These sensors use IAS messaging and the IAS enrolling process while pairing must complete successfully.
- And lastly - it happens that AE sellers send devices from different batches / different manufacturers even in one and the same purchase order. Check if all the 6 devices have one and the same Manufacturer and same Application version.
Is the 'Tuiya 4 in 1' driver selected automatically when you pair the sensor as a new device? I am not sure whether the inClusters list is correct. When pairing to HE as a new device, there is a 'more info' link - can you click on it and copy/paste ALL of the text that is shown in the popup window?
Searching for _TZE200_3towulqd shows at least two different fingerprints - one contains the Tuya specific EF00 clister, other fingerprints don't ... Is it possible to have two different variants of one and the same device model and manufacturer?
The one sensor that is working OK with your setup - which event comes first: the motion or the illuminance? What is the delay between the two events?
'OK' for me means there is less than 1 second delay between moving near the sensor and my light turning on. Illuminance fires first every time and then there is about a 250 msec delay to motion is 'active'. Motion is not always active and illuminance false triggers quite a bit, Its not clear in my logs which are real motions and which are false alarms.
Have in mind these ÁliExpres 'specifics :) ' :
- often the batteries that come with the cheap sensors are of a very low quality. You may still measure 3V with an high impedance voltmeter, but the crappy battery internal resistance is so high, so that when the device starts to transmit the Zigbee messages (especially during the intensive communication when paired to the hub) the voltage drops and the device may be reset or the transmission to be corrupted. Replace the cell battery with a new one while pairing the sensor to the hub.
I have some batteries on order, hopefully they improve response. I did check the voltage with a cheapo meter and it was 3.3V, gave me a false sense of battery power
- check whether the battery holder metal plates make good contact to the cell. Bend them a little if needed.
Did this on two of them, the side tab wasn't making solid enough contact
- always pair the sensors very close to the hub. If the pairing is successful, you can move it later to the final destination, then press shortly the pair button and the device will quickly find a Zigbee repeater if needed. These sensors use IAS messaging and the IAS enrolling process while pairing must complete successfully.
I paired them in place, I didn't know about the pair button trick to find a new repeater. Is this all zigbee devices - just a short press of the pair button? It did take several pairing attempts to get full control
- And lastly - it happens that AE sellers send devices from different batches / different manufacturers even in one and the same purchase order. Check if all the 6 devices have one and the same Manufacturer and same Application version.
The boxes they came in all had the same model: ZG-204Z. Hubitat shows them all as the same manufacturer _TZE200_3towulqd and model TS0601.
Is the 'Tuiya 4 in 1' driver selected automatically when you pair the sensor as a new device?
Yes, the Tuya 4 in 1 is selected automatically. It hasn't worked with the first pair ever, I had to delete and re-pair them for all of the modules I have before it showed illuminance and motion as states. On first pair, it only showed powerSource as battery.
I am not sure whether the inClusters list is correct. When pairing to HE as a new device, there is a 'more info' link - can you click on it and copy/paste ALL of the text that is shown in the popup window?
Manufacturer: | _TZE200_3towulqd
Endpoint 01 application: | 40
Endpoint 01 endpointId: | 01
Endpoint 01 idAsInt: | 1
Endpoint 01 inClusters: | 0001,0500,0000
Endpoint 01 initialized: | true
Endpoint 01 manufacturer: | _TZE200_3towulqd
Endpoint 01 model: | TS0601
Endpoint 01 outClusters: | 0019,000A
Endpoint 01 profileId: | 0104
Endpoint 01 stage: | 4
Oh, I also forgot. When changing the sensitivity and keeptime, it looks like the device sends back a message of the current setting. Sensitivity is consistently coming back as a 0 regardless of high/med/low selection sent
Thanks for the info. So the inClusters in the driver are correct. The 250 ms delay for firing the motion active event comes from the device itself, the delays in the driver should be negligible.
about the pair button trick to find a new repeater. Is this all zigbee devices - just a short press of the pair button? It did take several pairing attempts to get full control
A short press usually forces the battery-powered devices to send a battery level report to the zigbee coordinator, often it helps to find a route via the best repeater nearby. No other special functions.
It hasn't worked with the first pair ever, I had to delete and re-pair them for all of the modules I have before it showed illuminance and motion as states. On first pair, it only showed powerSource as battery.
I have noticed similar problems with other devices that use the IAS messaging - often the first pairing is unsuccessful.
Sensitivity is consistently coming back as a 0 regardless of high/med/low selection sent
I think I have found a bug there. Please update the driver to the dev. branch link version 1.0.13 time stamp 2022/09/25 8:48 PM
Please send me the debug logs when the preferences are saved (select 'medium' sensitivity), and then the parameters are reported back by the device.