I did already setup on one of them but having the same issue, even more this devices stay stuck on motion forever and the tamper stay red, UV to 0
I did a secure join (double tap on sensor). Just for kicks, I blew everything away - devicetype & excluded sensor from ST. Joined it securely, copy/pasted the raw github code into a new devicetype, but still get funky errors. I think thereās some syntax issues, but a) not looking at it in depth enough and/or b) not being familiar with groovy, I see a couple things that stand out:
Iām focusing on the temp section, simply because thatās my primary use case at this point. Accurate temperature.
What Iām seeing in that section of the config code block:
def tempoff = tempoffset
if (negtempoffset == "true") {
tempoff=(0-tempoff)
//log.debug "--Negative Temperature Flag Set--"
}
tempoff *= 10
Should be:
def tempoff = tempoffset
tempoff.toInteger()
if (negtempoffset == "true") {
tempoff=(0-tempoffset).toInteger() //was tempoff=(0-tempoff)
//log.debug "--Negative Temperature Flag Set--"
}
tempoff = tempoff * 10 //was tempoff *= 10
I also had to ditch the conditional logic for the previous issue I mentioned starting at line 467. state.sec wasnāt being interpreted right and this is the only way I could get that Live Logging error to go away.
private command(physicalgraph.zwave.Command cmd) {
//if (state.sec) {
zwave.securityV1.securityMessageEncapsulation().encapsulate(cmd).format()
//} else {
//cmd.format()
//}
}
Finally, after getting the debug errors fixed, I kept getting an error on line 456. For troubleshooting, I simply commented it out, but I think thatās the command that does the heavy lifting, so I need to figure out a way to make it not throw an exception. I think there is a missing parameter the command is expecting.
commands(request) + ["delay 20000", zwave.wakeUpV1.wakeUpNoMoreInformation().format()]
Unfortunately, Iām still at square one at this point with no way to configure a temp delta. For now, Iām rolling with the ST Multisensor 6 device type, but think all the work @bs87 and @Robert_Vandervoort have done is outstanding! Worst case scenario is that I just configure my smart apps with the temp offsets in mind.
@Kevin_Nadjarian forgot to add the link
I am not sure what is going on with yours. You donāt need to cast to integer, it is already an integer based on
input ("tempoffset",
"number",
title: "Temperature offset",
description: "Only 0 through 10 is valid",
defaultValue: 0,
required: false,
displayDuringSetup: false)
I think maybe you have a non-number in your calibration field for tempoffset? Try creating a new device type and paste in the code (iāve seen weird editing issues in the IDE so sometimes creating a new type fixes stuff), then go to your device, change it to your new type, then double check your preferences have 0 or a valid value in each of the fields.
The code does work as-is so something funky is going on with your set up. Can you copy\paste the errors you are seeing?
I found something odd. I have been using both the RV and BS device types (Thank You both for that!) and last night one of my sensors stopped working. It turns out the batteries were dead. Now none of my 4 sensors has ever reported anything but 100% battery power so this came as a surprise. When I replaced the batteries an odd condition occurred. Imagine you have the sensor in front of you, back panel off, with the battery diagram showing the + facing upwards/ away form you. When replacing the batteries if you replace the right battery the sensor will pop to life and report 50% battery available. This will not change when you replace the second battery, however the sensor appears to function and begin reporting. If you instead replace the left side battery first you will get no response from the unit. When you then replace the right side battery the until will turn on and report 100% battery life. Is this a response anyone else has fond?
While weāre at it, does anyone know the status of the official device type? I know there is one in the device manager but it didnāt appear for use when I integrated by last two sensors. Thanks!
I ran across the device type not auto populating āAeon Multisensor 6ā today to when including it to ST, too. It simply connected as a āZwave Sensorā sometime after 9AM.
Iāve probably excluded/included this device a dozen times in testing, and today was the first time it didnāt auto-detect. Not a problem to have to go into the IDE and manually change it, but makes one think if there wasnāt something going on behind the scenes.
Very interesting, I know the spec sheet says the default for triggering a battery report is a 10% change but beyond that I havenāt really tested it as I just put brand new batteries in and it hasnāt been up for very long. I will keep an eye on mine and see if it drops to the 90%
How long did you run on batteries? Curious what the actual battery life will be like.
The official device type works but lacks the entire feature set and calibration abilities. Mine didnāt need calibration but most users report that out of the box values are not accurate and do need calibrated so the official type is a no-go.
So did the code work for you this time even though it didnāt detect right?
I have had issues where a device was detected incorrectly or not at all and i had to power cycle my hub then everything started working again.
I put this one in back in July but I would have to double check if I used Lith-Ion batteries or not.
Hello BS87,
Thank you for your work and Robert Vandervoort, this is awsome!
I clearly understand the code but my first pb (and the worst) is that i could not sync the MultiSensor 6 with my STā¦
I read all the topic and did not find THE answer which could help me.
I created a new Device Type (with your code). I double tap on the Multisensor but nothing happened⦠Did i miss something?
I bought 3 of theses just to link it to my STā¦
Thanks by advance,
And sorry for my bad englishā¦
Matt
If you are having trouble I would unplug power and pull a battery from your hub, then plug it all back in and try join again.
To join just double tap the button on your multisensor within 1 second and it should show up to add in your app. It will add with the default device type which is feature-limited. Then you just change it with mine or Roberts device type and you should get all the features.
Thanks for this great code and getting everything up and running on this sensor.
Not sure if intentional - or maybe my misunderstanding of the code - but looks like temperature offset in version 1,5 can only be set to whole numbers of degrees and not to tenths as allowed for in the Aeon Tech spec?
The small tweaks on line 155 and 158 below lets you enter a temperature offset between -10.0 and 10.0 degrees into the preferences field i.e. with decimal point . This then gets scaled up and rounded by a small change on line 386 to make sure we have an integer in the [-100ā¦100] range needed by the sensor.
I was puzzled by the various range: āā¦ā lines in the preferences section. I couldnāt find a reference to that syntax in the documentation. Did I miss something ? I have used range: ā-10.0ā¦10.0ā on line 158 to put the necessary validation checking on the temp offset field to make sure we stick within the Aeon Tech specification. Also, in the SmartThings Groovy documentation it states that āwithout specifying a range that allows negative numbers, the mobile clients will only show a keypad to allow positive numeric entriesā.
Anyway, the changes I made are on lines 155, 158 and 386 as below. This is my first attempt at Groovy so not particularly confident but it seems to work ⦠at least on this one iPhone !
154 input ātempoffsetā,
155 ādecimalā, // Changed from ānumberā to ādecimalā to allow tenths of degree to be entered
156 title: āTemperature offsetā,
157 description: ānegative values reduce the monitored value positive ones add to itā,
158 range: ā-10.0ā¦10.0ā, // Changed from āā¦ā to ensure entry is validated within specified range
159 defaultValue: 0,
160 required: false,
161 displayDuringSetup: false
and,
386 tempoff=Math.round(tempoffset*10) // Round after scaling so tempoff is integer in [-100ā¦100] range
SmartThings broke their own code. There is a security check they do that is illegal. After you join the sensor, go into the IDE under your devices, edit the device and change the device type to either mine or @bs87 version. His works with iphone or android, mine only works on iphone.
the join signal is very weak from my experience. I always join it to the hub a couple feet away. If the sensorās multicolor light isnāt cycling through the different colors that means it was already joined. If that is the case and itās NOT listed in smartthings, hold the action button on the back down for about 30 seconds until the light blinks red quickly and then returns to cycling through colors. Then put ST back into inclusion mode and try double tapping the action button again.
Iāll give that a try. I wonder if that fixes the issue with the android app⦠Iāll have to do testing on it tomorrow⦠Long day today and every time I get in that IDE Iām there all night! Thanks for the research Pete. When I read the ST docs there was no mention of range either. I found it in another device type and then forgot about it and then someone on this (reallly long!) thread pointed it out to me again. Validation is an important thing and Iām a big fan. There is some hackery going on in the device type that Iām not super proud of, but I was racing to get it working 100%. And on that note, you ALL are freaking awesome. This is a great community. Iām amazed at how many responses there are to this thread and how much help and feedback weāve gotten.
Yes, thatās exactly what we needed! You were so close.
Just canāt have a decimal in your range.
The math.round is not working. Looking up the syntax and it looks right but ST is just not liking it, throws an exception. Have to play with it later.
I donāt know if itās ST having issues right now but I was able to change the values a couple times but then it stopped changing on both old and new device type. It would save but when you go back to prefs it was back to the old value. Even restarted app, hub, and tried old device type. IDE works but once again app didnāt. I think its just a temp ST issue so try this one and let me know if it works.
Hopefully @Robert_Vandervoort can take a look and get the rounding working.
Weird, I am seeing range work with decimals limits i.e. range: ā-5.5ā¦10.6ā will accept -5.4 but reject 10.7. A bit academic when 10 is equivalent to 10.0 in this case but curious as to what error you were seeing?
Couldnāt find a way of locking down the preference field to a single decimal point i.e. someone could enter say 3.55, hence the use of the Math.round() function. I think Math.round() needs a capital M as its a class reference.
Thx bs87,
I did exactly what you said :
- Remove all what iāve done on smartthings device type
- Unplug power AND battery from my hub
- Plug it in back
- Double Click on the weird button of my multisensor
- In my App (Connect New device section), nothing happensā¦
It is turning me crazyā¦
Iāve got a Multisensor 6 ZW100-C: is the āCā the problem?
Thank you again,
Matt.
Ahh, yes it is the capital M. Didnāt realize it was case sensitive. Updated in the 1.9 version.
The decimal in the range may be syntactically correct but it causes the preference page to crash in the android app.
Just a question; does anyone know whether or not ST supports OTA firmware updates for these devices? Does it push those automatically if so?