@erocm1231 My Motion is working fine, PIR was 5. Tamper not updating.
I tried setting PIR to 0 then setting it to 5 just to see if the change reset cache or something, no go still tamper is not updating.
As of curiosity I have tried another handler to make sure sensors are not defective and tamper worked fine…
Sounds like the configuration upload to the device may be the culprit, at least for me.
Now that tamper detection (acceleration) is working again. I did some further testing.
I caused the sensor to trip the tamper without causing motion. When I do this it caused the “Tamper Active” to show. However the Tamper Active will not change back to “Tamper Clear” unless motion is detected and then detects no motion. As soon as motion stops the Tamper Active changes to Tamper Clear.
@Mikee Alright, I have a couple theories about the tamper status not showing for you. I have made a couple of changes that might work around them, so give them a shot. One theory is that SmartThings displays value tiles funky sometimes. I’ve changed that tile to a standardTile. So, one thing I want you to check is if it is showing the wrong status on the main page of the handler, switch over to the “Recently” tab and see if their is any activity there. That will tell me that it is a display issue.
@an39511 A lot of devices, including this one, will send a tamper alert report, but never a “clear report”. The motion clear thing is kind of a work around that has been in different versions of this handler. I believe the proper way to do it was actually mentioned in these forums by a SmartThings employee. Implementing a “resetTamperAlert” command that can be used with a button, but it seems that when the tamper capability was finalized earlier this year, it was officially left out.
Anyway, I wrote that in as a custom command so if you press the tamper icon when it is active, it will reset. This way, even if you have the motion capability disabled, you can still use the tamper functionality.
@erocm1231 Hip Hip, Hooray! Success, worked like a charm. Thank you Eric for all the work you put in.
I’ve updated all my sensors to 1.07 (EU) - however this handler never shows that in the details?
They also always say “pending” and never synced. No amount of waiting makes a difference. I have 8 of these in my house, all on 1.07, all behaving the same way.
Motion and all that other stuff still works though
also they are only able to do the non secure include with this handler
It looks like my firmware’s checksum is 14569… must be a EU thing.
Sorry for the bombardment of messages… this may help you for EU:
case "11942":
firmwareVersion = "1.06"
case "14569":
firmwareVersion = "1.07"
break;
I’m also noticing that parameters entered in the settings are not the same ones that get set as per the logs…
I’ll need to add the checksum for the EU version to the device handler. They look like what you posted and should show in the SmartApp or the device page of the IDE under “firmware”.
Also, which parameter specifically? Some have to be adjusted so they may look off in the logs.
Looks like parameter 41 is the issue
Utility MultiSensor parameter ‘41’ with a byte size of ‘3’ is set to '2561’
then:
Parameter 41 will be updated to 10
basically permanently loops this - so clearly it cant set it
There may be other parameters with issues as well that aren’t showing up yet
This is one of the parameters that needs to be adjusted. In firmware 1.06 it is 2 bytes and is interpreted exactly how you put it in (i.e. 10). In firmware 1.07 & 1.08 it is 3 bytes and has to be adjusted from what the user inputs. The reason it is in a loop is because I have not made the adjustment for the EU version, I really can’t unless I know the checksums for those versions. This is the documentation for 1.07. If you notice any other parameters that are off, let me know, but as this is the main one that needs adjustment I think it may be the only one.:
41 (0x29) Threshold change in temperature to induce an automatic report.
Note:
1. The unit is Fahrenheit for US version, Celsius for EU/AU version.
2. High byte is the threshold value. Low byte is the unit (0x01=Celsius,
0x02=Fahrenheit).
3. The threshold value (high byte) contains one decimal point. E.g. if the
value is set to 20 (0x001401), the threshold value =2.0 °C (EU/AU
version) or if the value is set to 20 (0x001402), the threshold value= 2.0
°F (US version). When the current temperature is changed more then
2.0, which will induce a temperature report to be sent out.
20
(0x001401 for
EU/AU/CN
version.
0x001402 for
US version )So I gave you the checksum for the EU firmware… I’m not sure what other checksum you need… let me know and I’ll get it for you - otherwise… I’m not sure what I can dow with this information
Also - I think it would be a good idea to update the handler to support secure inclusion
FYI there is no 1.08 firmware for EU yet so the two checksums I gave you were the only ones for EU firmware
I’ve edited the device handler myself but just updating the firmware detection does’nt solve the parameter 41 issue
The handler already supports secure inclusion.
As for parameter 41, of course it doesn’t fix it. The document shows the adjustment is different for the EU version. I’ll have to modify the adjustment method with the new firmware string.
Eric, I really appreciate the work you’ve done on this handler. Yo have made configurations useful in a way that I had not been privy o before and that is much appreciated. However I do find it unfortunate that you were not able to overcome the 1hr reporting threshold in the manner that others have. Is this something you feel you may be able to overcome in the future as doing so would make this handler more or less perfect.
I am really confused. I have my sensors reporting in increments as small as every 60 seconds for USB powered and every 5 minutes for battery powered. The only exception is that there is some funkiness with firmware 1.08 and certain sensors. Where are you seeing that that is not a possibility with this handler?
I still can’t get it lower than 60min.
Had the setting on 300, changed it to 600 just to try it out, but the settings is “pending”. It’s been like that a couple of days now
@AdamV There is a new version with added EU compatibility. Try it out and let me know if parameter 41 is working. I don’t have an EU version to test of course, but it looks like it should work.
@Widzinschinke Are you assuming that reporting can’t be configured to less than 60 minutes based on the one report in this thread or based on experience? If experience, let me know the firmware version, the setting you are trying, and whether it is USB or battery powered.
@cscheiene I am using a more aggressive method of upgrading parameters so I just want to make sure you have one of the latest versions of the handler installed. The device stays awake for a very small amount of time, so by the time the message gets up to the cloud and the commands get sent back to the sensor, it may already be back asleep. In the latest versions, I am predicting that the device is waking up based on the sensor reports that get sent, and sending the parameter changes at that time. This has been very successful so far. If you have the latest version, can you turn on debugging in the device preferences and post it here? I’ll be looking for the line that says “device woke up”. I’ve tested 600 on firmware 1.07 several times without any issues.