Aeotec Multisensor 6 Z-Wave firmware 1.14

[csteele]

I don't fully comprehend the differences in speed between a Zigbee Motion Sensor and a ZWave motion sensor. I can clearly see there is one. Zigbee is faster. This v1.14 is supposed to be faster, and that would be great, but the devices I've updated so far are not in locations where I can detect an important difference.

I like the MS6 on the other hand. The 6 sensors in one package is great and where placement is tweeked to hide the inherent delay, they are great for me. Small bathrooms, where one can get halfway in before the light comes on is where I do not have the MS6. I'll use Zigbee or Dome's Zwave for that spot. Livingroom, kitchen, etc. which are large and that detect motion just a small bit outside the 'boundary' have been perfect.

An example of extended boundary detection is in my Master Bath. I have MS6 just inside the door and so I can get one, even two steps inside before the light comes on. I have a motion sensor in the Master Bed that 'pre-triggers' the light.. I detect motion and turn on the bathroom light at a low level (11%) and for 15 seconds. If the motion detected happens to head into the bathroom, then there is light and it quickly brightens. The MS6 inside the bathroom keeps the light on for several minutes longer. Then a third sensor, watching the shower space only, will extend the time even more.

[shawnx1]

My question was pretty broad but you actually gave me exactly what I was wanting.

[inetjnky]

Something still isn't right for me in my bathroom where humidity detection is critical to ensuring the fan comes on when a shower is running. It's not "refreshing" properly with the 1.14 firmware and the 2.0.1 driver from @csteele on main power (not battery). When I take a shower with the door closed, the fan never turns on, even though the room is completely steamed up. When I open Hubitat and bring up the MS6 in that room, and click "refresh" the humidity goes straight to 100% and the fan turns on. But I have to manually click refresh for it to work. Didn't have to do this with 1.13 or the 2.0.0 driver. Still trying to determine which it is. But I'm leaning towards the firmware at this point but will try reverting the driver as that's the easiest test to start with. Worked good on 1.13 and the 2.0.0 driver.

[csteele]

I'd revert to v2.0.0 because limits were one of the big changes made to v2.0.1.

if (cmd.scaledSensorValue >= LIMIT_VALUES.rh.upper || cmd.scaledSensorValue < LIMIT_VALUES.rh.lower) return

If the sensor sends a value larger or smaller, the event is discarded. rh: [upper: 100, lower: 0]

A debug log entry will appear for the RAW value but then the debug log for "finalval" will not appear. In other words, normal is to have two debug log messages per returned value, one raw, one final. Abnormal would have only one debug log, the raw.I'd revert to v2.0.0

The Change Notes indicate that limits were added to all the values, including Humidity. It was added to return a value between an upper and lower limit.

If your Sensor is returning humidity values greater than 100% or less than 0%, then those would be dropped.. well that's the intent. Maybe it's working different in reality?

[inetjnky]

I reverted back to 2.0.0 and the fan is back to turning on by itself, albiet it feels like it's taking longer for it to actually sense and turn on. Not sure if it's the 5 min interval setting I have set in the prefs in Hubitat on the device or not.

Would it be possible to set the HPM back to 2.0.0 as the latest version so it doesn't keep barking?

[inetjnky]

Sensor:

dev:20912021-02-13 02:40:08.868 pm infoHumidity is 60%

dev:20912021-02-13 02:40:08.601 pm infoTemperature is 77.8°F

dev:20912021-02-13 02:37:31.950 pm infoAcceleration is inactive by NotificationReport

dev:20912021-02-13 02:37:31.949 pm infoTamper cleared by NotificationReport

dev:20912021-02-13 02:37:31.656 pm infoMotion is inactive by SensorBinaryReport

dev:20912021-02-13 02:35:10.263 pm infoUltraviolet index is 0

dev:20912021-02-13 02:35:10.016 pm infoIlluminance is 13 Lux

dev:20912021-02-13 02:35:08.957 pm infoHumidity is 64%

dev:20912021-02-13 02:35:08.695 pm infoTemperature is 76.7°F

dev:20912021-02-13 02:30:10.312 pm infoUltraviolet index is 0

dev:20912021-02-13 02:30:10.091 pm infoIlluminance is 10 Lux

dev:20912021-02-13 02:30:09.018 pm infoHumidity is 100%

dev:20912021-02-13 02:30:08.758 pm infoTemperature is 73.5°F

dev:20912021-02-13 02:25:26.593 pm infoMotion is active by SensorBinaryReport

dev:20912021-02-13 02:25:10.379 pm infoUltraviolet index is 0

dev:20912021-02-13 02:25:10.177 pm infoIlluminance is 0 Lux

dev:20912021-02-13 02:25:09.069 pm infoHumidity is 33%

dev:20912021-02-13 02:25:08.838 pm infoTemperature is 68.8°F

dev:20912021-02-13 02:20:10.484 pm infoUltraviolet index is 0

dev:20912021-02-13 02:20:10.239 pm infoIlluminance is 0 Lux

dev:20912021-02-13 02:20:09.157 pm infoHumidity is 34%

dev:20912021-02-13 02:20:08.918 pm infoTemperature is 67.9°F

dev:20912021-02-13 02:15:10.527 pm infoUltraviolet index is 0

dev:20912021-02-13 02:15:10.298 pm infoIlluminance is 0 Lux

dev:20912021-02-13 02:15:09.256 pm infoHumidity is 34%

Bathroom Humidity App:

app:4532021-02-13 02:35:09.038 pm infoHumidityHandler:running humidity check

app:4532021-02-13 02:30:09.259 pm infoFanSwitchHandler::Switch changed

app:4532021-02-13 02:30:09.145 pm infoHumidityHandler:Turn On Fan due to humidity increase

app:4532021-02-13 02:30:09.126 pm infoIsHumidityPresent: Humidity is above the Threashold

app:4532021-02-13 02:30:09.112 pm infoHumidityHandler:running humidity check

app:4532021-02-13 02:25:09.150 pm infoHumidityHandler:running humidity check

app:4532021-02-13 02:15:09.343 pm infoHumidityHandler:running humidity check

Looks like it's fine

[inetjnky]

I am finding it interesting though that the interval report I have set is 5 minutes, however as you can see from the logs, the humidity went from 34% to 100% without a report interval in between.

My preferences on the device is to report if humidity rises by 10% regardless of the reporting interval if I'm interpreting the preferences correctly.

[csteele]

The reporting is certainly every 5 min: 02:30:09.018, 02:25:09.069, 02:20:09.157, 02:15:09.256 to the second.

[inetjnky]

Is my thinking correct that the reporting should be checking in at a 10% change in humidity? And is so, is that controlled by the driver or the firmware?

[csteele]

The driver simply converts user inputs into ZWave commands to the Device. So the fact that you enter 10 into a specific field of the UI allows the driver to get that value and "format it" per the Device's specification for that function. I've captured a sliver of the device's engineering document to show what I mean.. the right most column is the number of bytes the device is expecting.

And that's the 'formatting' I'm referring to here. You can enter 10 in both those fields but one of them needs to be sent as 0x0A while the other must be sent as 0x000A.

Note that the second rightmost column is the default value. 10% for Humidity.

Therefore it's the driver's job to take the user's input values and send it to the device to use. How the device uses that value is up to the device.

[inetjnky]

So maybe it’s the change in the firmware after all. I’ll monitor for a few days and see what happens. Thanks!

[AdamV]

@csteele - in the firmware update change log for 1.14 it says that:

Basic Set faster report trigger when motion detected (when Parameter 5 [1 byte] = 1)

I’ve noticed when pressing configure your driver changes parameter 5 to 2.

I’ve changed it manually to 1 but I wanted to see if your driver is using this basic set command to register the motion... so that we can get the benefit of the faster response

[AdamV]

just as a follow up to this in case anyone is interested - I changed the driver to default to set 5 to 1 - and there is a noticeable speed improvement for basic motion. I would say that its still not as fast as some other motion sensors.. but its a significant improvement on where this device was before, and totally acceptable

[shawnx1]

So set Parameter 5 to byte=1 value=1 ? I switched over to default driver and parameter 5 was still byte 1 value 2
either way its still slow compared to others. my MS6's days are numbered

[AdamV]

So parameter 5 to value 1. The driver defaults every time you configure to setting it to 2 so you’ll need to edit the driver to change that.

Also you’ll still need to ensure that your z wave mesh is properly set up and not a mess (very easy to make it messy) and that all your rules are efficient and not triggering unnecessarily). I put a lot of time into those last parts as well. I’ve got 9 Aeotec multi sensors on the latest firmware, with the parameter 5 change and it’s registering motion in less that a second on all of them

[erktrek]

So I've had a lot of troubles with the MS6's in the past flaky repeating was the worst of it but I really liked the powered option - not many other sensors had this at the time.

Had a bunch in our basement where speed was not quite as critical. Have 3 left all on the edge of my network - One left in the basement (swapped the others out for Inovelli 4-in-1s), One in the detached garage and one on our back deck in a clear weather-resistant enclosure (lux detection only).

Upgraded all of them to 1.14 a little while ago and things have been stable. I'm kind of coming around to them again for certain situations maybe.

The other thing I did was mod a bunch of Iris motion sensors adding usb power. They work really well and if you have any on hand and want a powered solution it's definitely worth considering.

[shawnx1]

@AdamV

Also you’ll still need to ensure that your z wave mesh is properly set up and not a mess

Sorry but all I can to is laugh at that one. Pretty sad when that's go do cause when someone says something is slow on HE. My Zwave network is as good as it's going to get, more than enough repeaters thousands of $ worth and everything is stable and fast best it's been in years. My MS6's are stable work well but compared to others their just slow or maybe it's their range, but can still be used for like turning on lights on the way to another room. MS6's best feature is recessed mounting. I set parameter 5 to 1 manually with zwave tool seems the same to me, I was really hoping to see a difference I think my problem is I know how fast other motions sensors trigger and lights turn on. Zigbee is so much faster for whatever reasons at least in my houses it's that way.

[AdamV]

@shawnx1

Pretty sad when that's go do cause when someone says something is slow on HE.

It's not a go to excuse for HE... it's a statement of fact. Z-wave meshes are particularly finicky, and its not so much about how many repeaters you have (too many can make it worse), its about how it's set up (see info on the forum about setting up a backbone).

I'm sorry if you haven't seen fast responses from the MS6 - I'm seeing under a second across the board now on all of mine, so I'm happy with the results of the firmware update to 1.14. It's still not as good as other motion sensors I've seen and used (some of which seem to be well under 0.5s) but it's more than good enough for motion lighting applications IMO

[shawnx1]

Lol I didn't say anything about it being an excuse but okay that's a fact too. If I haven't been able to setup my zwave network correctly by now then there's no hope for me with zwave another fact. Like I said my network is running fine and stable everything responds fast not about to mess with it for MS6's. which I know for another fact are really slow compared to Zigbee and other zwave motion sensors when it comes to using them as triggers for motion lighting.
All my MS6's get numbers like this when testing seem to be working okay to me. Still slow when using for motion lighting. If they work good for you awesome. It's not rocket science nor does it take some special skills to set up a zwave network it's actually fairly simple.

living room dimmers are in there seem to be working fine as well. Pretty sure I can't make any improvements in my zwave network. O that's right smash that Zwave repair 100 times and make sure i don't have any ghost

[erktrek]

I wish that were true..unfortunately there are a lot of factors at play in my experience including clean sources of power (faulty wiring, capacity), interference from other devices - Wifi with Zigbee / noisy machines like Microwave Ovens / equipment that draws large amounts of electricity / outside sources, construction materials and how the signals (Zigbee/Z-Wave) propagate through the location, device location relative to each other and the hub, types of devices - battery powered, repeating/non-repeating/Legacy devices, version of communication protocols used by devices and hub, local networking issues (cabling, switching, setup), defective devices, physical hub issues like overheating, bad power supply/connection...

If all of that is okay/tolerable then potential software issues - how the hub has charted a path to each device (routing decisions), what type of security is used for Z-Wave, how strong the mesh is, ghost devices, ghost routes, HE firmware issues, Silicon Labs Firmware issues (C-7 only), app issues, device firmware issues, device driver issues, device polling issues, incorrect rules, internal network config, location/time settings issues...

Am probably missing some stuff as well...

The bottom line is many strange things can affect the integrity of the system and because things usually just work it's easy to make the assumption that it should always be so for any given location.

This is why I think we as consumers have been led astray a bit about how simple these things really are in terms of a whole usable system thanks to fancy marketing by the tech industry..