Aeotech Multisensor 6 (gen 5 zwave plus, model ZW100-A)

After ST finds the device and I hit Next, its throwing an “unexpected error”. Any ideas?


I bought 5 Aeon MultiSensor 6,

I finally managed to pair with the hub, but UV is set to 0,
And motion present is incorrect. (even if the motion is only a few seconds, the motion remains on for 5 minutes.)

The vibration (and UV) is not displayed on the app, and the log often goes from “socket unhealthy to healthy” but this is most of my Z-Wave devices though.

The light rules take long before turning on.

Also, can’t managed to add the last 2 sensors, they are detected and when I change the name and save I have “an unexpected error occurred”. Same after remove and pair again a few time

I’ve try to add a new devices with the script bellow, but not sure I did it well, should I be able to see it on the list of devices in the iOS app?


@kevin_barbarian you might want to look at this link below and read on it. You will have to create a new device type and link it to your device.

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") {
       //log.debug "--Negative Temperature Flag Set--"
tempoff *= 10

Should be:

def tempoff = tempoffset
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) {
	//} else {

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",
		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…


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
386 tempoff=Math.round(tempoffset*10) // Round after scaling so tempoff is integer in [-100…100] range

1 Like

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.

1 Like

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! :slight_smile: 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. :smile:

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.